• 博客访问: 467550
  • 博文数量: 337
  • 用 户 组: 普通用户
  • 注册时间: 2008-01-01 20:58
个人简介

暂无介绍

ITPUB论坛APP

ITPUB论坛APP



APP发帖 享双倍积分

文章分类

全部博文(337)

文章存档

2011年(1)

2010年(22)

2009年(35)

2008年(41)

2007年(143)

2006年(39)

2005年(56)

我的朋友
微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

分类: 数据库开发技术



之前的NETAPP存储一直使用的是默认的MOUNT协议,也就是NFS3的协议,因为一个应用需要使用NFS4的协议,于是开始了苦难之旅。

首先默认情况下NFS4协议在NETAPP存储上是没有打开的,这个打开很容易,基于WEB的图形界面没有配置的地方的,只能通过命令行进行配置。登录进 去,然后使用options nfs.v4.enable on命令打开NFS4协议,这时候会提示说在冗余机头的情况下,那边机头也要搞,否则发生FAILOVER的时候那边就不能提供NFS4服务了,于是把两 边都搞好,在VOL上划了个QTREE,把QTREE EXPORT出去,然后就开始在客户端折腾。[@more@]

首先是客户端MOUNT不上去,报错如下:
Warning: rpc.idmapd appears not to be running.
All uids will be mapped to the nobody uid.
mount: block device 192.168.1.1:/vol/vol1/xxx is write-protected, mounting read-only
Warning: rpc.idmapd appears not to be running.
All uids will be mapped to the nobody uid.
mount: cannot mount block device 192.168.1.1:/vol/vol1/xxx read-only

WARNING很容易理解,说IDMAPD服务没起,所以所有的UID映射过来都会被映射成NOBODY的UID,这个只要启了IDMAPD服务就好了,使用service rpcidmapd start命令去启。但后面的就很难理解了,为什么会说是写保护的,然后要被MOUNT称只读的,然后即使是只读的也MOUNT不上去呢?关键最难以理解的是为什么明明是MOUNT一个NFS的设备,提示确实说BLOCK DEVICE不能被MOUNT,为什么就成了BLOCK DEVICE呢?
GOOGLE+BAIDU+NOW.NETAPP.COM+REDHAT.COM搜索了半天,没有什么进展。换个机器试试吧,因为这个机器不是自己安装的,不确定是否缺什么包啥的。于是换了个机器,暂且叫新机器(之前的机器就叫老机器),虽然还是报IDMAPD的报警,但是结果确实MOUNT上去了,晕了,看来是老机器有问题。

也正是这个很巧合能MOUNT的问题,导致了后面一路的误判,寻找问题中出现了方向性错误,浪费了很多的时间。

开始把两边的后台服务搞成一样,不行;比较OS版本,一致;比较网络访问权限,没问题,因为测试中老机器使用NFS3协议能顺利MOUNT;折腾了半天实在没辙,所有招数都用尽了,突然想起来了STRACE。先做个STRACE看看整个MOUNT过程中到底干了些什么,卡在哪一步出现的错误吧。

做了STRACE后发现最后错误的地方在:
mount("192.168.1.1:/vol/vol1/xxx", "/u09", "nfs4", MS_MGC_VAL, "1") = -1 EACCES (Permission denied)
也就是会有一个权限的错误,这又是一个误导我的地方。因为NFS3能MOUNT,MOUNT上去后能读写,那说明不应该出现权限相关的问题啊。拿着新老机器的STRACE去做对比,新的机器在这一步的返回结果如下:
mount("192.168.1.1:/vol/vol1/xxx", "/u09", "nfs4", MS_MGC_VAL, "1") = 0
看来问题就是出在这里了,而且相同版本的OS,相同版本的NFS相关的包,一个可以一个不可以,那只能看看是否是BUG了。还别说,真的还就找到了一个BUG,在REDHAT的官网上,BUGID=197504(nfs4 AUTH_GSSAPI server returning EACCESS on all mount attempts ),里面说在nfs-utils-1.0.9-3版本中修复了这个BUG,虽然BUG发生的版本跟我使用的版本不一致,这个BUG描述的是出现在nfs-utils-1.0.8-2,而我使用的版本是nfs-utils-1.0.6,但很多时候ORACLE就经常这么干,只是说新的版本中发现并验证了这个问题,并不代表老的版本一定没有这个问题,很可能这个问题一直就有,只不过在某个版本中被发现了。

于是下载了0.9的版本,结果很悲剧,装不上。这个版本很新,所以依赖的东西太多,而且很多是很底层的东西,看来想装上去是不行了,但是这个BUG里描述了一个PATCH的解决办法,只要改一段源代码,然后重新编译下就好了,看起来挺可行的。因为BUG出现在0.8,不确定我使用的0.6中代码是否一致以及估计我连CTRL+C然后CTRL+V都找不到地方,所以下了0.8的,结果编译的时候还是报一堆的依赖关系没有,这下绝望了。


既然这条路不通,那试试新的版本吧,有装好的5.4的REDHAT,这个上面的NFS版本很新,结果测试了居然也不行,跟老机器报的错一模一样,接连试了几个机器,都不行,这就见鬼了,为什么只有新机器可以,所有其他机器都不行呢,但也是在找不出新机器跟其他机器之间的不同在哪里。

在绝望的时候,希望终于来了,在NOW.NETAPP.COM上找到了Solution ID: kb13800 的一个文章,里面描述到:
With NFSv4, client "mount" requests proceed with LOOKUP sequences to parse names from the root. As a result, if a parent directory is exported such that name lookup is blocked to a child, then the mount will fail.

踏破铁鞋无觅处,得来全不费功夫啊,到存储上一看,新机器以前为了做测试,直接加过/VOL/VOL1级别的读写权限,所以去MOUNT它下面的QTREE就符合上面的条件,所以也只有它能MOUNT的上去,其他所有人都MOUNT不上去。之前一个简单的测试,竟然给问题的解决带来这么多的误导,无语啊。


找到了原因,问题解决就简单多了,只要把需要访问的机器全部把QTREE的上级目录的读权限加上就全部OK了
阅读(4967) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册