NFS服务启动异常

welman00chijian 2011-06-02 08:35:11

我在服务器上装了Ubuntu 10.04, 配置了NFS用来共享几台Clients的HOME目录, Clients设置的是开始自动mount的。
一开始活动挺正常的。昨天在几台Client启动的情况下,重启了服务器。然后发现,现在Server启动后,NFS的服务不正常了,Client不能自动挂载NFS了,手动挂载亦不成功,提示是:
mount to NFS server 'node1:/export/homes' failed: RPC Error: Success
如果我在服务器端手动重启NFS,然后一切正常了。

推断是服务器的问题,我用
cat | grep -iE '(rpc|nfs)' 的方式查看了/var/log/messages 和 /var/log/syslogs
没有发现异常的输出:
Jun 2 14:12:07 node1 rpc.statd[1134]: Version 1.1.6 Starting
Jun 2 14:12:07 node1 rpc.statd[1134]: Flags:
Jun 2 14:12:07 node1 kernel: [ 13.438549] RPC: Registered udp transport module.
Jun 2 14:12:07 node1 kernel: [ 13.438549] RPC: Registered tcp transport module.
Jun 2 14:12:07 node1 kernel: [ 13.438549] RPC: Registered tcp NFSv4.1 backchannel transport module.
Jun 2 14:12:07 node1 kernel: [ 13.467135] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Jun 2 14:12:08 node1 kernel: [ 13.795788] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
Jun 2 14:12:08 node1 kernel: [ 13.803972] NFSD: starting 90-second grace period
看起来像是顺利启动了。利用rpcinfo -p localhost | grep nfs 可以看到
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
同时,netstat 查看2049端口:
tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN -
udp 0 0 0.0.0.0:2049 0.0.0.0:* -
可以看到2049已被NFS采用,并处于listen的状态。

如果我重启一下nfs服务,则手动挂载就没有问题了。
syslog显示:
Jun 2 14:32:11 node1 kernel: [ 1216.968817] nfsd: last server has exited, flushing export cache
Jun 2 14:32:12 node1 kernel: [ 1218.043658] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
Jun 2 14:32:12 node1 kernel: [ 1218.043686] NFSD: starting 90-second grace period
除了重新flush了一下export cache之后,没有什么别的差别。
如果我手动地来重置一下export,
sudo exportfs -arv
则client不能挂载上。

不过我现在还有一个情况不清楚,在我重启NFS之前,利用showmount看了一下当前的挂载IP,显示
showmount -a localhost
All mount points on localhost:
192.168.0.2:/export/homes
冒似client已经挂载上了, 这里的192.168.0.2是一台client的IP.
但应该并不是client的问题,因为如果当NFS恢复正常后,我再重启client,是可以自动挂载上去的。

我大概的分析就只到这里了,还请各位多多指教,谢谢!
...全文
2091 1 打赏 收藏 转发到动态 举报
写回复
用AI写文章
1 条回复
切换为时间正序
请发表友善的回复…
发表回复
welman00chijian 2011-06-02
  • 打赏
  • 举报
回复
问题解决了,但原理还不太清楚。
在mount时,加了一个参数,-o nfsvers=2
用来指定是version2 的NFS版本,这就没问题了。同时在client的fstab里加载参数中,把这个nfsvers=2加进去,就可以自动加载了。
看了一下NFS的mannual,其中说mount.nfs时,默认的nfsvers是3. 同时在server通过
rpcinfo -t localhost nfs可以看到,2,3,4的版本也同时在ready。
所以还不太明白为什么必须指定2的版本才可以。
暂不关帖,望高手指教。

同时,说个题外话,我之前在查看/var/log/messages时,看到有这样一个错误:
kernel: [ 11.176079] svc: failed to register lockdv1 RPC service (errno 97).
当时以为这个是原因,后来找了一下,这主要是由于Ubuntu默认支持IPV6而造成的。
通过在/etc/default/grub中,修改GRUB_CMDLINE_LINUX项为
GRUB_CMDLINE_LINUX="ipv6.disable=1"
就可以禁掉ipv6,消掉这个error了。
但这个问题和NFS的问题没有直接的关系。
第1章 HDFS HA及解决方案 1.1 HDFS系统架构 1.2 HA定义 1.3 HDFS HA原因分析及应对措施 1.3.1 可靠性 1.3.2 可维护性 1.4 现有HDFS HA解决方案 1.4.1 Hadoop的元数据备份方案 1.4.2 Hadoop的SecondaryNameNode方案 1.4.3 Hadoop的Checkpoint ode方案 1.4.4 Hadoop的BackupNode方案 1.4.5 DRDB方案 1.4.6 FaceBook的AvatarNode方案 1.5 方案优缺点比较 第2章 HDFS元数据解析 2.1 概述 2.2 内存元数据结构 2.2.1 INode 2.2.2 Block 2.2.3 BlockInfo和DatanodeDescriptor 2.2.4 小结 2.2.5 代码分析——元数据结构 2.3 磁盘元数据文件 2.4 Format情景分析 2.5 元数据应用场景分析 第3章 Hadoop的元数据备份方案 3.1 运行机制分析 4 3.1.1 NameNode启动加载元数据情景分析 3.1.2 元数据更新及日志写入情景分析 3.1.3 Checkpoint过程情景分析 3.1.4 元数据可靠性机制 3.1.5 元数据一致性机制 3.2 使用说明 第4章 Hadoop的Backup Node方案 4.1 Backup Node概述 4.1.1 系统架构 4.1.2 使用原则 4.1.3 优缺点 4.2 运行机制分析 4.2.1 启动流程 4.2.2 元数据操作情景分析 4.2.3 日志池(journal spool)机制 4.2.4 故障切换机制 4.3 实验方案说明 4.4 构建实验环境 4.4.1 网络拓扑 4.4.2 系统安装及配置 4.4.3 安装JDK 4.4.4 虚拟机集群架设 4.4.5 NameNode安装及配置 4.4.6 Backup Node安装及配置 4.4.7 Data Node安装及配置 4.4.8 Clients安装及配置 4.5 异常解决方案 4.5.1 异常情况分析 4.5.2 NameNode配置 4.5.3 Backup Node配置 4.5.4 Data Node配置 4.5.5 NameNode宕机切换实验 4.5.6 NameNode宕机读写测试 第5章 AvatarNode运行机制 5.1 方案说明 5.1.1 系统架构 5.1.2 思路分析 5.1.3 性能数据 5.2 元数据分析 5.2.1 类FSNamesystem 5.2.2 类FSDirectory 5.2.3 AvatarNode的磁盘元数据文件 5.3 AvatarNode Primary启动过程 5.4 AvatarNode Standby启动过程 5.4.1 AvatarNode的构造方法 5.4.2 Standby线程的run()方法 5.4.3 Ingest线程的run()方法 5.4.4 Ingest线程的ingestFSEdits ()方法 5.4.5 Standby线程的doCheckpoint()方法 5.5 用户操作情景分析 5.5.1 创建目录情景分析 5.5.2 创建文件情景分析 5.6 AvatarNode Standby故障切换过程 5.7 元数据一致性保证机制 5.7.1 元数据目录树信息 5.7.2 Data Node与Block数据块映射信息 5.8 Block更新同步问题 5.8.1 问题描述 5.8.2 结论 5.8.3 源码分析 第6章 AvatarNode使用 6.1 方案说明 6.1.1 网络拓扑 6.1.2 操作系统安装及配置 6.2 使用Avatar打补丁版本 6.2.1 Hadoop源码联机Build 6.2.2 Hadoop源码本地Build 6.2.3 NFS服务器构建 6.2.4 Avatar分发与部署 6.2.5 Primary(namenode0)节点配置 6.2.7 Data Node节点配置 6.2.8 Client节点配置 6.2.9 创建目录 6.2.10 挂载NFS 6.2.11 启动Ucarp 6.2.12 格式化 6.2.13 系统启动 6.2.14 检查 6.2.15 NameNode失效切换写文件实验 6.2.16 NameNode失效切换读文件实验 6.3 Avatar FaceBook版本的使用 6.3.1 Hadoop FaceBook版本安装 6.3.2 节点配置 6.3.3 启动HDFS 6.3.4 NameNode失效切换 第7章 AvatarNode异常解决方案 7.1 测试环境 7.2 Primary失效 7.2.1 解决方案 7.2.2 写操作实验步骤 7.2.3 改进写操作机制 7.2.4 读操作实验步骤 7.2.5 小结 7.3 Standby失效 7.4 NFS失效(数据未损坏) 7.4.1 解决方案 7.4.2 写操作实验步骤 7.4.3 读操作实验步骤 7.4.4 小结 322 7.5 NFS失效(数据已损坏) 7.5.1 解决方案 7.5.2 写操作实验步骤 7.5.3 读操作实验步骤 7.5.4 小结 7.6 Primary先失效,NFS后失效(数据未损坏) 7.6.1 解决方案 7.6.2 写操作实验步骤 7.6.3 读操作实验步骤 7.6.4 小结 7.7 Primary先失效(数据未损坏),NFS后失效(数据损坏) 7.7.1 解决方案 7.7.2 写操作实验步骤 7.7.3 读操作实验步骤 7.7.4 小结 7.8 NFS先失效(数据未损坏),Primary后失效 7.8.1 解决方案 7.8.2 写操作实验步骤 7.8.3 读操作实验步骤 7.8.4 小结 7.9 NFS先失效(数据损坏),Primary后失效(数据损坏) 7.9.1 解决方案 7.9.2 写操作实验步骤 7.9.3 读操作实验步骤 7.9.4 小结 7.10 实验结论 第8章 Cloudera HA NameNode使用 8.1 HA NameNode说明 8.2 CDH4B1版本HDFS集群配置 8.2.1 虚拟机安装 8.2.2 nn1配置 8.2.3 dn1~dn3配置 8.2.4 HDFS集群构建 8.3 HA NameNode配置 8.3.1 nn1配置 8.3.2 其他节点配置 8.4 HA NameNode使用 8.4.1 启动HA HDFS集群 8.4.2 第1次failover 8.4.3 模拟写操作 8.4.4 模拟Active Name Node失效,第2次failover 8.3.5 模拟新的Standby NameNode加入 8.5 小结

19,612

社区成员

发帖
与我相关
我的任务
社区描述
系统使用、管理、维护问题。可以是Ubuntu, Fedora, Unix等等
社区管理员
  • 系统维护与使用区社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧