免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 6391 | 回复: 8
打印 上一主题 下一主题

[存储网络] 请教:光纤连接存储没有安装共享软件情况下磁盘文件的同步问题 [复制链接]

论坛徽章:
0
跳转到指定楼层
1 [收藏(0)] [报告]
发表于 2015-05-05 16:05 |只看该作者 |倒序浏览
      项目中存储最初规划了nfs,但是随着用户的逐渐增多,并发访问增大,经常出现远程nfs目录反映慢的问题。iostat发现磁盘阵列达到瓶颈。
      存储原本有配有光纤,通过光交和两台流媒体服务器相连,因为nfs达到了瓶颈,于是采取不走nfs,直接走光纤,负载下去了(项目之初原本想做GFS的,
因为某些原因没有做,做了NFS)。
      产生的新问题就是:三台主机直接挂载光纤连接的分区,一台写,两台读。其他两台对于第一台写入的新的文件并不能实时读取到。
查了一些资料,了解到“多主机共享一个lun,数据是不同步的,各有各的缓存,也没有锁的机制”,“nfs的传输时文件级的,而fc san是块级的”。

      由于是生产环境,不能重新部署GFS,OCFS,SANergy,ImageSAN等共享软件,我的问题是:

1)既然各主机各有各的缓存,这个缓存是在主机还是存储控制器上的?如果是在主机上,能否像Oracle一样,通过checkpoin强制把缓存的数据写入磁盘阵列?
2) 但是对1)仍有疑问,因为挂载分区后,两台读的主机三天了还没有能看到写主机三天前写的新的数据。好像重新mount可以看到?生产环境在跑,还没试验。
3)对于当前需求,一台写,两台主机读,有什么办法在不安装共享软件的情况下,实时读取写主机上更新的数据吗?(另两台只需要读取,不需要写)
4)如果以上皆不可行,对nfs能做何优化使之能承受越来越大的并发访问压力?

    本人对存储方面经验,了解都很有限,还请各位大牛指教......

论坛徽章:
13
技术图书徽章
日期:2014-04-29 14:15:42IT运维版块每日发帖之星
日期:2015-12-12 06:20:00IT运维版块每日发帖之星
日期:2015-08-30 06:20:00IT运维版块每日发帖之星
日期:2015-08-24 06:20:00IT运维版块每日发帖之星
日期:2015-08-02 06:20:002015年亚洲杯之澳大利亚
日期:2015-04-03 15:03:12申猴
日期:2015-03-20 09:00:292015年迎新春徽章
日期:2015-03-04 09:54:452015年辞旧岁徽章
日期:2015-03-03 16:54:15季节之章:冬
日期:2015-01-20 17:08:47双子座
日期:2014-11-21 16:30:31技术图书徽章
日期:2014-07-11 16:29:08
2 [报告]
发表于 2015-05-05 16:14 |只看该作者
最可靠的方法是用支持共享读写的文件系统和相关软件,否则会发生读写不一致性

我记得某些存储可以可以NAS的,也就是用SAN存储实现NAS的功能,如果你无法使用基于共享的文件系统的话

论坛徽章:
0
3 [报告]
发表于 2015-05-06 10:05 |只看该作者
zdcdcz 发表于 2015-05-05 16:05
项目中存储最初规划了nfs,但是随着用户的逐渐增多,并发访问增大,经常出现远程nfs目录反映慢的问题 ...


非常遗憾的告诉你:针对流媒体业务,以你目前的架构,不做很大的改动很难解决你的痛处。
SAN是专有的“块”级访问模式,效率高但具有唯一性,你说的写入后无法反映在读取的另外节点,数据应该是临时被缓冲在主机的文件系统了。
NFS或其它的NAS协议属于文件级访问,可以共享,不过就像你说的效率低,尤其文件到达一定的数量,几万,十几万,几百万的时候就下降十分厉害。

那,最好的方式就是,你必须改造目前的架构,在磁盘上方搭建一套分布式文件系统,可以集合所有节点性能,同时提供多个系统同时读/写。
往常这种系统可以用SAN的方式发布空间,比如iSCSI,高性能同时还提供文件锁,写入数据实时反映在读—节点上。

论坛徽章:
0
4 [报告]
发表于 2015-05-06 11:25 |只看该作者
回复 2# dengbao2001
你是说基于光纤的NAS?但是从定义上来说,基于光纤的就不是NAS了

这个倒是没有听说过?您有资料吗?


   

论坛徽章:
0
5 [报告]
发表于 2015-05-06 11:29 |只看该作者
回复 3# 锅铁做

谢谢兄弟指点,看来不经过文件系统的改造,很难取得性能上的提高,所以项目初期就应该规划好啊......

又或是,nas使用万兆网卡,部署集群,不知能否改善nfs的性能,适应流媒体的高负载?

   

论坛徽章:
0
6 [报告]
发表于 2015-05-06 12:24 |只看该作者
zdcdcz 发表于 2015-05-06 11:29
回复 3# 锅铁做

谢谢兄弟指点,看来不经过文件系统的改造,很难取得性能上的提高,所以项目初期就应该规 ...


可以试一下,不过有两点需要注意:

第一:到底是带宽瓶颈还是磁盘的响应速度跟不上?你开篇第一句话说的是磁盘响应速度跟不上,如果是这样,扩展带宽对改善问题帮助不大。
第二:保留目前的架构,只能回到NAS(用SAN不合理),使用NFS,这是一种文件协议和链路没关系,不要混淆。用NAS的话链路可以是1或10Gb的网卡,也可以是10Gb的光纤以太网,并不是说光纤就必须是SAN。但光的延迟总会小于双绞线吧。
我之前计划用SAN去替换客户已有的流媒体业务,发现越到后期问题越多,也包括阁下目前遇到的所有问题,所以最好是专有的分布式文件系统才合理。

论坛徽章:
13
技术图书徽章
日期:2014-04-29 14:15:42IT运维版块每日发帖之星
日期:2015-12-12 06:20:00IT运维版块每日发帖之星
日期:2015-08-30 06:20:00IT运维版块每日发帖之星
日期:2015-08-24 06:20:00IT运维版块每日发帖之星
日期:2015-08-02 06:20:002015年亚洲杯之澳大利亚
日期:2015-04-03 15:03:12申猴
日期:2015-03-20 09:00:292015年迎新春徽章
日期:2015-03-04 09:54:452015年辞旧岁徽章
日期:2015-03-03 16:54:15季节之章:冬
日期:2015-01-20 17:08:47双子座
日期:2014-11-21 16:30:31技术图书徽章
日期:2014-07-11 16:29:08
7 [报告]
发表于 2015-05-06 13:18 |只看该作者
到了现在才知道你用了流媒体形式,不知可否用分布式+缓存这种部署方式

论坛徽章:
0
8 [报告]
发表于 2015-05-07 14:53 |只看该作者
回复 6# 锅铁做
多谢回复。

1)应该是链路上的瓶颈。存储做了raid,23块硬盘并发写入,应该不至于有问题。而且现在暂时采用的方案是一台流媒体采用nfs,两台直接走光交连接存储,目前
     iostat显示的await  svctm  %util等参数都正常了,流媒体也没有出现过读取不到文件的情况。只是有前述的问题,光纤连接的读取不到新写入的文件。

2)改用光纤以太网应该会改善一点性能,但不知道能不能顶住目前流媒体的压力。事实上,目前生产环境已经在跑业务,而且是电子政务,做大的改动比较困难。所以说,
     项目初期就要做好规划,预留压力空间。

     我要么把情况上报领导,之前的想在不动现有环境的情况下解决估计可能性不大。还是看领导意思吧,哈

   

论坛徽章:
0
9 [报告]
发表于 2015-05-07 15:07 |只看该作者
回复 7# dengbao2001

我们另一个较大的项目用到了分布式,以及CDN来分担压力,但这个项目已经在运营,不能做大的改动了,当然,这也涉及成本,呵呵


   
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP