在存储服务器中,我创建了一个GFS2 FS来保存连接到drbd的数据.我之所以选择GFS2,主要是因为宣布了性能,还因为体积大小必须相当高.
自从我们进入生产以来,我一直面临着两个与我认为密切相关的问题.
首先,Web服务器上的NFS挂载会持续一分钟左右,然后恢复正常操作.通过分析日志,我发现NFS停止响应一段时间并输出以下日志行：
Oct 15 18:15:42 <server hostname> kernel: nfs: server active.storage.vlan not responding,still trying Oct 15 18:15:44 <server hostname> kernel: nfs: server active.storage.vlan not responding,still trying Oct 15 18:15:46 <server hostname> kernel: nfs: server active.storage.vlan not responding,still trying Oct 15 18:15:47 <server hostname> kernel: nfs: server active.storage.vlan not responding,still trying Oct 15 18:15:48 <server hostname> kernel: nfs: server active.storage.vlan not responding,still trying Oct 15 18:15:51 <server hostname> kernel: nfs: server active.storage.vlan not responding,still trying Oct 15 18:15:52 <server hostname> kernel: nfs: server active.storage.vlan not responding,still trying Oct 15 18:15:55 <server hostname> kernel: nfs: server active.storage.vlan not responding,still trying Oct 15 18:15:58 <server hostname> kernel: nfs: server active.storage.vlan OK Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
在这种情况下,挂起持续16秒,但有时需要1或2分钟才能恢复正常操作.
我的第一个猜测是由于NFS挂载的大量负载而发生这种情况,并且通过将RPCNFSDCOUNT增加到更高的值,这将变得稳定.我已经增加了几次,显然,一段时间后,日志开始出现次数减少了.该值现在为32.
在进一步研究该问题之后,尽管NFS消息仍然出现在日志中,但我遇到了不同的问题.有时,GFS2 FS会挂起,导致NFS和存储Web服务器都提供文件.两者都保持一段时间,然后他们恢复正常运作.这种挂起在客户端没有留下任何痕迹(也没有留下任何NFS ……没有响应消息),并且在存储端,即使rsyslogd正在运行,日志系统也显示为空.
节点通过10Gbps非专用连接连接自己,但我不认为这是一个问题,因为GFS2挂起已确认,但直接连接到活动存储服务器.
我已经尝试解决这个问题了一段时间我已经尝试了不同的NFS配置选项,在我发现GFS2 FS也悬挂之前.
NFS挂载导出如下：
/srv/data/ <ip_address>(rw,async,no_root_squash,no_all_squash,fsid=25)
NFS客户端安装：
mount -o "async,hard,intr,wsize=8192,rsize=8192" active.storage.vlan:/srv/data /srv/data
经过一些测试后,这些配置可以为集群带来更多性能.
我迫切希望找到一个解决方案,因为集群已经处于生产模式,我需要解决这个问题,以便将来不会发生这种情况并且我不确定我应该做什么以及如何进行基准测试.我能说的是,由于我已经对集群进行了早期测试,而且这些问题根本没有发生,所以由于负载很重而发生了这种情况.
请告诉我您是否需要我提供群集的配置详细信息,以及您希望我发布哪些内容.
作为最后的手段,我可以将文件迁移到不同的FS,但是我需要一些可靠的指针来确定这是否能解决这个问题,因为此时卷大小非常大.
服务器由第三方企业托管,我没有物理访问权限.
最好的祝福.
编辑1：
服务器是物理服务器,其规格如下：
>网络服务器：
> Intel Bi Xeon E5606 2×4 2.13GHz
> 24GB DDR3
>英特尔SSD 320 2 x 120GB Raid 1
>存储：
>英特尔i5 3550 3.3GHz
> 16GB DDR3
> 12 x 2TB SATA
最初在服务器之间有一个VRack设置,但是我们已经升级了一个存储服务器以拥有更多RAM而且它不在VRack中.它们通过它们之间的共享10Gbps连接进行连接.请注意,它与用于公共访问的连接相同.他们使用单个IP(使用IP故障转移)在它们之间进行连接,以实现正常的故障转移.
因此,NFS是通过公共连接而不是在任何专用网络下(在升级之前,问题仍然存在).
防火墙已经过彻底配置和测试,但是我暂时禁用它以查看问题是否仍然存在,并且确实发生了问题.据我所知,托管服务提供商没有阻止或限制服务器和公共域之间的连接(至少在尚未达到的给定带宽消耗阈值下).
希望这有助于解决问题.
编辑2：
相关软件版本：
CentOS 2.6.32-279.9.1.el6.x86_64 nfs-utils-1.2.3-26.el6.x86_64 nfs-utils-lib-1.1.5-4.el6.x86_64 gfs2-utils-3.0.12.1-32.el6_3.1.x86_64 kmod-drbd84-8.4.2-1.el6_3.elrepo.x86_64 drbd84-utils-8.4.2-1.el6.elrepo.x86_64
存储服务器上的DRBD配置：
#/etc/drbd.d/storage.res
resource storage {
protocol C;
on <server1 fqdn> {
device /dev/drbd0;
disk /dev/vg_storage/LV_replicated;
address <server1 ip>:7788;
Meta-disk internal;
}
on <server2 fqdn> {
device /dev/drbd0;
disk /dev/vg_storage/LV_replicated;
address <server2 ip>:7788;
Meta-disk internal;
}
}
存储服务器中的NFS配置：
#/etc/sysconfig/nfs RPCNFSDCOUNT=32 STATD_PORT=10002 STATD_OUTGOING_PORT=10003 MOUNTD_PORT=10004 RQUOTAD_PORT=10005 LOCKD_UDPPORT=30001 LOCKD_TCPPORT=30001
(对LOCKD_UDPPORT和LOCKD_TCPPORT使用相同的端口会有任何冲突吗？)
GFS2配置：
# gfs2_tool gettune <mountpoint> incore_log_blocks = 1024 log_flush_secs = 60 quota_warn_period = 10 quota_quantum = 60 max_readahead = 262144 complain_secs = 10 statfs_slow = 0 quota_simul_sync = 64 statfs_quantum = 30 quota_scale = 1.0000 (1,1) new_files_jdata = 0
存储网络环境：
eth0 Link encap:Ethernet HWaddr <mac address>
inet addr:<ip address> Bcast:<bcast address> Mask:<ip mask>
inet6 addr: <ip address> Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:957025127 errors:0 dropped:0 overruns:0 frame:0
TX packets:1473338731 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2630984979622 (2.3 TiB) TX bytes:1648430431523 (1.4 TiB)
eth0:0 Link encap:Ethernet HWaddr <mac address>
inet addr:<ip failover address> Bcast:<bcast address> Mask:<ip mask>
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
IP地址静态分配给定的网络配置：
DEVICE="eth0" BOOTPROTO="static" HWADDR=<mac address> ONBOOT="yes" TYPE="Ethernet" IPADDR=<ip address> NETMASK=<net mask>
和
DEVICE="eth0:0" BOOTPROTO="static" HWADDR=<mac address> IPADDR=<ip failover> NETMASK=<net mask> ONBOOT="yes" BROADCAST=<bcast address>
主机文件允许在两个存储服务器上设置NFS选项fsid = 25时进行正常的NFS故障转移：
#/etc/hosts <storage ip failover address> active.storage.vlan <webserver ip failover address> active.service.vlan
正如您所看到的,数据包错误已降至0.我也已经运行ping很长一段时间没有任何数据包丢失. MTU大小是正常的1500.由于现在没有VLan,这是用于在服务器之间通信的MTU.
Web服务器的网络环境类似.
我忘记提到的一件事是存储服务器每天通过NFS连接处理大约200GB的新文件,这是我认为这是NFS或GFS2的某种重负载问题的关键点.
如果您需要进一步的配置详情,请告诉我.
编辑3：
今天早些时候,我们在存储服务器上遇到了严重的文件系统崩溃.我无法立即得到崩溃的细节,因为服务器停止响应.重新启动后,我注意到文件系统非常慢,我无法通过NFS或httpd提供单个文件,可能是因为缓存变暖等等.尽管如此,我一直在密切监视服务器,并在dmesg中出现以下错误.问题的根源显然是GFS,它等待锁定并在一段时间后结束饥饿.
INFO: task nfsd:3029 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. nfsd D 0000000000000000 0 3029 2 0x00000080 ffff8803814f79e0 0000000000000046 0000000000000000 ffffffff8109213f ffff880434c5e148 ffff880624508d88 ffff8803814f7960 ffffffffa037253f ffff8803815c1098 ffff8803814f7fd8 000000000000fb88 ffff8803815c1098 Call Trace: [<ffffffff8109213f>] ? wake_up_bit+0x2f/0x40 [<ffffffffa037253f>] ? gfs2_holder_wake+0x1f/0x30 [gfs2] [<ffffffff814ff42e>] __mutex_lock_slowpath+0x13e/0x180 [<ffffffff814ff2cb>] mutex_lock+0x2b/0x50 [<ffffffffa0379f21>] gfs2_log_reserve+0x51/0x190 [gfs2] [<ffffffffa0390da2>] gfs2_trans_begin+0x112/0x1d0 [gfs2] [<ffffffffa0369b05>] ? gfs2_dir_check+0x35/0xe0 [gfs2] [<ffffffffa0377943>] gfs2_createi+0x1a3/0xaa0 [gfs2] [<ffffffff8121aab1>] ? avc_has_perm+0x71/0x90 [<ffffffffa0383d1e>] gfs2_create+0x7e/0x1a0 [gfs2] [<ffffffffa037783f>] ? gfs2_createi+0x9f/0xaa0 [gfs2] [<ffffffff81188cf4>] vfs_create+0xb4/0xe0 [<ffffffffa04217d6>] nfsd_create_v3+0x366/0x4c0 [nfsd] [<ffffffffa0429703>] nfsd3_proc_create+0x123/0x1b0 [nfsd] [<ffffffffa041a43e>] nfsd_dispatch+0xfe/0x240 [nfsd] [<ffffffffa025a5d4>] svc_process_common+0x344/0x640 [sunrpc] [<ffffffff810602a0>] ? default_wake_function+0x0/0x20 [<ffffffffa025ac10>] svc_process+0x110/0x160 [sunrpc] [<ffffffffa041ab62>] nfsd+0xc2/0x160 [nfsd] [<ffffffffa041aaa0>] ? nfsd+0x0/0x160 [nfsd] [<ffffffff81091de6>] kthread+0x96/0xa0 [<ffffffff8100c14a>] child_rip+0xa/0x20 [<ffffffff81091d50>] ? kthread+0x0/0xa0 [<ffffffff8100c140>] ? child_rip+0x0/0x20
编辑4：
我安装了munin,我有一些新的数据出来了.今天有另一个挂起,munin告诉我以下内容：inode表大小在挂起之前高达80k然后突然下降到10k.与内存一样,缓存数据也会突然从7GB降至500MB.挂起期间的负载平均值也会出现峰值,并且drbd设备的设备使用率也会达到90％左右.
与之前的挂起相比,这两个指标的行为相同.这可能是由于应用程序端的文件管理不良而不释放文件处理程序,或者是来自GFS2或NFS的内存管理问题(我怀疑)？
感谢任何可能的反馈.
编辑5：
Munin的Inode表用法：
Munin的内存使用情况：
解决方法
首先,我将获得一些简单的基准测试指标.至少那时你会知道你所做的改变是否是最好的.
>穆宁
>仙人掌
> Nagios
是一些不错的选择.
这些节点是虚拟服务器还是物理服务器,它们的规格是什么.
每个节点之间有什么样的网络连接
是否通过托管服务提供商专用网络进行NFS设置
您不限制带防火墙的数据包/端口,您的托管服务提供商是否这样做？
