NAS存储N8500(V200R001C00LNH001SPC102)NFS共享访问缓慢

发布时间:  2017-04-17 浏览次数:  280 下载次数:  1
问题描述

    
农行某局点工程师发现运行于N8500存储NFS共享上的Domino公文系统无响应,其他业务响应缓慢,业务几乎中断

告警信息

1、 现场N8500集群日志可见N8500集群状态正常。

2、现场N8500集群日志显示NAS引擎侧在故障时间点只有正常的NBU备份文件系统快照日志信息,无集群异常、文件系统异常、共享异常打印。

 

3、当前现场N8500所有的业务IP都分布在节点二,因此业务压力都分布在节点二上。排查节点二的锁记录文件,可以看到同一时刻Domino公文系统对NFS共享文件有大量的加锁行为,经统计采样点已累计约13500个加锁操作。






 
图中第6列对应文件系统和加锁的文件(f282对应文件系统nfs_soi_n01),第7列和第8列对应文件所加锁的起始及结束字节。从上图可见,大量的加锁操作均为字节级别的锁,加锁范围仅1字节,这种加锁行为由客户端发起且极其罕见。由于锁操作无法缓存,每次操作均会下发到磁盘,大量的锁请求会使得磁盘IOPS剧增。











处理过程



1.  手动关闭Domino公文系统后,所有客户端共享访问恢复正常。



根因

频繁的字节级加锁操作及Domino公文系统大量的IOPS操作,使该文件系统的IO请求逐渐进入排队状态,这会导致NFS服务进程NFSD处理该共享的请求时由于IO等待进入D状态。与此同时由于公文系统与其他系统不断的发起请求,就会使所有的NFSD服务进程长时间处于D状态,最终导致该节点对外响应缓慢。


另外,由于所有业务都集中一个节点上,导致所有客户端都出现访问缓慢的现象。现场通过停止Domino公文系统业务减少了加锁处理操作,极大的减少了系统负载压力,最终业务恢复正常。



解决方案



1.      
从性能数据中统计的数据能够看到,Domino公文系统为IOPS密集型的业务模型,这类业务对业务带宽要求不高,但对IO要求很高,因此不建议运行在当前的场景中。



2.      
调整现场NFS服务进程NFSD并发数。(已完成,现场调节到96)。



3.      
现场业务IP地址全部都在单个引擎节点中,在业务空闲的时间窗口,将业务IP地址进行负载均衡,使两个引擎节点能够同时负载业务。



建议与总结

1、Domino公文系统为IOPS密集型的业务模型,不建议运行于这类业务对业务带宽要求不高,但对IO要求很高,因此不建议运行在N8500存储NFS共享场景中。

2、N8500存储应将业务IP地址进行负载均衡,使两个引擎节点能够同时负载业务。



END