it-swarm.cn

哪种网络文件共享协议具有最佳性能和可靠性?

我们有一个带有负载均衡的几个Web服务器的设置。我们希望拥有所有Web服务器都可以访问的某种网络共享存储。它将用作存储用户上传的文件的地方。一切都在运行Linux。

我们应该使用NFS,CIFS,SMB,Fuse + sftp,Fuse + ftp吗?网络文件共享协议有很多选择,很难选择。我们基本上只想将这一共享永久安装在多台机器上。安全功能不是问题,因为除了安装它的服务器之外,其他任何地方都无法通过网络访问它。我们只希望它可靠且快速地工作。

我们应该使用哪一个?

37
Apreche

我投票支持NFS。

NFSv4.1添加了并行NFS pNFS功能,这使得并行数据访问成为可能。我想知道如果仅使用类Unix的客户端会使用哪种存储,那么我将根据性能指标选择NFS。

29
Istvan

简短的答案是使用NFS。根据这个 shootout 和我自己的经验,它更快。

但是,您还有更多选择!您应该考虑一个群集FS像GFS,这是多个计算机可以一次访问的文件系统。基本上,您是通过iSCSI共享一个块设备,而iSCSI是GFS文件系统。所有客户端(iSCSI中的启动器)可以读写它。Redhat有 白皮书 。您也可以使用Oracle的集群FS [〜#〜] ocfs [〜# 〜] 来管理同一件事。

Redhat论文很好地列出了集群的优缺点FS vs NFS。基本上,如果您想有足够的扩展空间,则GFS可能值得努力。此外,GFS示例使用光纤通道SAN作为示例,但这可以很容易地是RAID,DAS或iSCSI SAN。

最后,请确保查看巨型帧,如果数据完整性至关重要,如果您将iSCSI与巨型帧一起使用,请使用CRC32校验和。

21
Andrew Cholakian

我们有2个服务器负载均衡网络集群,我们尝试了以下方法在服务器之间同步内容:

  • 每10分钟与[〜#〜] rsync [〜#〜]同步的每台服务器上的本地驱动器
  • 到两个服务器的中央CIFS(SAMBA)共享
  • 中央[〜#〜] nfs [〜#〜]共享给两个服务器
  • 共享的SAN正在运行的驱动器OCFS2

[〜#〜] rsync [〜#〜]解决方案是最简单的,但是它花了10分钟才能显示更改,并且RSYNC投入了很多服务器上的负载,我们不得不使用自定义脚本对其进行限制,以使其每秒暂停一次。我们还被限制为仅写入源驱动器。

性能最快的共享驱动器是OCFS2群集驱动器,直到它疯狂并崩溃为止。我们无法使用OCFS2保持稳定性。只要一台以上的服务器访问相同的文件,负载就会从屋顶爬升,服务器开始重新启动。这可能是我们方面的培训失败。

次佳的是[〜#〜] nfs [〜#〜]。它非常稳定且具有容错能力。这是我们当前的设置。

SMB(CIFS)有一些锁定问题。特别是SMB服务器上的文件更改没有被Web服务器看到。SMB在故障切换SMB服务器

我们的结论是OCFS2具有最大的潜力,但在投入生产之前需要进行大量分析。如果您想要简单明了且可靠的产品,我建议使用带有心跳的NFS服务器群集进行故障转移。

18
Mark Porter

我建议您使用POHMELFS-它是由俄罗斯程序员Evgeniy Polyakov创建的,而且速度非常快。

5
Mateusz Kozak

在可靠性和安全性方面,可能是CIFS(又名Samba),但NFS似乎“轻”得多,并且通过仔细配置,可能无法将有价值的数据完全暴露给网络上的所有其他机器;-)

没有侮辱Fuse的东西,但是,如果您明白我的意思,它似乎还是……新鲜的。我不知道我是否还相信它,但是那可能只是我是一个老烟枪,但是当涉及到有价值的企业数据时,有时还是需要老烟枪。

如果要永久性地将一个共享装载到多台计算机上,并且可以解决一些奇怪的问题(主要是UID/GID问题),请使用NFS。我使用它,并且已经有很多年了。

3
Matt Simmons

NFS。它是可靠的,并且您可以进行坚如磐石的设置。 GFS的性能通常很差,特别是在具有大量小文件的文件系统上。我没有使用过OCFS,但是我通常不喜欢群集文件系统的概念。然后是Lustre,但这是另一罐蠕虫…….

2
Shawn

我可能会晚一点,我们使用具有集群双端口的MD3220 Dell Storage,我们的设备有2个控制器,以防一秒钟掉下来将使它继续运行,直到解决该问题为止。由于硬盘,风扇,电源和控制器都是热插拔的,因此我们需要更换零件。从格式开始,我们使用NFS。

1
Kevin Zafari

我建议不要使用NFS。简而言之-我们有一个Web服务器场,其中的JBoss,Apache,Tomcat和Oracle都使用NFS共享来存储公共配置文件和日志记录。

当NFS份额消失时(这是罕见的情况),整个事情就崩溃了(真的可以预测,我建议“开发者”反对这种配置时间捷径)。

我们使用的NFS版本似乎存在问题,如果目标在写入过程中消失了,客户端将陷入永无休止的等待循环,等待NFS目标返回。即使重新连接了NFS盒-循环仍然没有结束。

我们混合使用了RHEL 3、4、5。存储位于RHEL4上,服务器位于RHEL5上,存储网络是一个单独的局域网,不在vlan上运行。

如果前端有负载平衡,请检查单个存储-这不会成为系统的瓶颈吗?

您是否考虑了到存储的只读iSCSI连接,并且使用事件驱动脚本在文件上传时通过ftp/scp将上传的文件移动到存储中?

我唯一一次为多个读取头实现成功的集中式存储的地方是在EMC存储阵列上……所有其他经济高效的尝试都有其缺点。

1
Iain

被认为是GFS? GFS是一个群集文件系统,以我的经验,它是非常可靠的。它可以有多个期刊,扩展性也很好

但是您将需要安装一些群集服务,并且GFS的快速性并不确切。 Otoh,它对我来说一直足够快,但是ymmv。

1
wzzrd

您可能会觉得像GFS这样的分布式FS.

如果您想简单地使用NFS。它简单,快速,并且软安装相当坚固。还可以考虑禁用所有随之而来的锁定垃圾。我有Linux桌面,可以从NFS抓取所有主目录和应用程序,它工作正常。

如果您想获得惊人的速度,那就选择Lustre,它比GFS的安装容易得多,并且非常类似于RAID NFS。我们为集群使用Lustre。

1
Jim Zajkowski

NFS的简单答案+1。我的NFS共享已经安装了很多年,没有发行问题。

如果您正在寻找超高可靠性,那么可以考虑将DRBD也用于分布式,自动故障转移NFS文件系统。

唯一的其他选项(我熟悉的)是iSCSI,但配置后部可能会很麻烦...

0
Rob Dudley

在大型服务器场中,我们有数百万个用户创建了html页面。 NFS不能很好地工作,因此我们最终将它们放在mysql表中。与遍历目录树相比,开销大约是相同的。

0
Bill

我想回应一些人对NFS发出的警告-尽管NFS可能是您最好的选择(听起来很奇怪)。

我有一个NFS客户端,由于NFS服务器消失了,我不得不与AC断开连接,并且由于NFS服务器消失了,客户端(在内核中)拒绝解锁或关闭。

为正确执行此操作,我将始终坚持使用NFSv4,坚持使用TCP连接,使用巨型帧并使用NFS群集。

0
Mei

您有很多选择,需要支付各种费用。与FC,iSCSI或更新的版本之一共享SAN。在任何情况下,它们的设置成本可能很高,并且您仍然需要运行支持群集的文件系统。群集文件系统是一个世界为了获得成功的希望,您需要单独的高速,低延迟的网络用于群集通信和数据,即使这样,您也可能会遇到小故障,导致节点陷入困境并被杀死。

我遇到的唯一可以轻松解决的群集文件系统是VMFS。但这是如此专门,即使将其用于一般用途也将毫无用处。

NFS可能是您进行设置的方法。如果您担心弹性,则需要获得适当的群集NFS盒。您可以进行自制安装,但会遇到上述问题。最好的选择(如果您有钱的话)是群集的NetApp文件管理器。这是一个昂贵的选择,但是集群实际上可以毫不费力地工作。不仅如此,它们非常快。

0
goo

GFS是一些严重的黑色伏都教徒。与备选方案相比,获得一个简单的两个客户端群集工作所需的工作量令人震惊。 OCFS2的部署要简单得多,但是涉及到所有连接的服务器上涉及的内核模块版本时,它非常挑剔-仅仅是开始。

除非您确实需要集群文件系统提供的那种低级访问,否则可能只需要NFS或CIFS。

0
allaryin

如果您到处都有Web服务器并且擅长运行它们,为什么不考虑使用WebDAV?

0
pjz