当前,我们将iSCSI SAN用作多个VMware ESXi服务器的存储。我正在研究在Linux服务器上将NFS目标用于其他虚拟机的情况。如果其他操作系统(例如OpenSolaris)具有明显的优势,那么我也持开放态度。
哪种基于Linux的文件系统支持非常大的连续文件(如VMware的磁盘映像)?或者,人们如何在此类工作负载的OpenSolaris上找到ZFS?
(此问题最初是在SuperUser上提出的;如果您知道如何,请随时在此处迁移答案)。
当前,我们将iSCSI SAN用作多个VMware ESXi服务器的存储。我正在研究在Linux服务器上将NFS目标用于其他虚拟机的情况。如果其他操作系统(例如OpenSolaris)具有明显的优势,那么我也持开放态度。
哪种基于Linux的文件系统支持非常大的连续文件(如VMware的磁盘映像)?或者,人们如何在此类工作负载的OpenSolaris上找到ZFS?
(此问题最初是在SuperUser上提出的;如果您知道如何,请随时在此处迁移答案)。
Answers:
我确实建议您看一下ZFS,但是要获得不错的性能,您需要选择专用设备作为ZFS Intent Log(ZIL)。基本上,这是一个小型设备(几GB),可以写得非常快(20-100K IOPS),这使ZFS可以立即确认写操作已同步到存储,但是要等待30秒才能将写操作实际提交到硬盘中。你的游泳池。如果发生崩溃/中断,则在挂载时会重播ZIL中任何未提交的事务。因此,除了UPS外,您可能还希望驱动器带有内部电源/超级电容器,以便在电源中断的情况下,任何待处理的IO都可以将其永久存储。如果您选择使用专用的ZIL设备,则写入可能会具有高延迟,从而导致各种问题。假设您对Sun不感兴趣,
一旦完成了OpenSolaris / Nexenta + ZFS的设置,就有许多种方法可以在OpenSolaris和ESX Boxen之间移动块。最适合您的选择取决于现有的基础架构(L3交换机,光纤卡)和优先级(冗余,延迟,速度,成本)。但是由于您不需要专门的许可证即可解锁iSCSI / FC / NFS功能,因此您可以评估拥有硬件的任何东西,然后选择自己喜欢的东西:
如果您不能花$ 500进行评估,请在禁用和不启用ZIL的情况下进行测试,以查看ZIL是否是瓶颈。(可能是)。不要在生产中这样做。除非您还拥有大量用于L2ARC的ram和SSD,否则请不要混淆ZFS重复数据删除。设置好它绝对很不错,但是您一定要在玩dedup之前尝试做一些NFS调整。一旦您将其饱和到1-2 Gb链路,则8gb FC,10gigE和infiniband都有增长的机会,但是即使评估,每个都需要大量投资。
我不会完全这样做。以我的经验,对于NFS服务器,Linux(特别是CentOS 3/4/5)通常是较差的选择。我遇到过几次,发现在负载下,延迟和吞吐量往往会下降,原因是我们永远无法完全避免。
在我们的案例中,我们正在将背对背Linux的性能与Solaris(在Ultra-SPARC上)和NetApp进行比较。两者返回的结果都是从苹果到苹果的性能,以及以“工程师在服务器负载不足时几乎不抱怨延迟”的模糊术语。曾多次尝试调整Linux NFS服务器。NetApps和Solaris系统都是开箱即用的。而且由于涉及的Solaris和NetApp系统都较旧,因此可以说Linux服务器具有所有优势,但仍然不能令人信服。
如果有时间,可以尝试使用OpenSolaris(现在使用Solaris实际价格太昂贵),Linux(可能是一两个BSD变体)来安装相同的硬件,并进行竞争。如果您可以提出一些性能指标(例如,存储在托管的VM中的磁盘I / O数量),则可能会成为有趣的白皮书或Internet文章。(如果有时间的话。)
一般而言,关于NFS,NetApp人士多次告诉我,他们的基准测试表明,NFS对VM的性能仅造成5%到10%的成本-如果您的应用程序足够敏感以至于这是一个问题,则不应进行虚拟化首先。
但我应该承认,经过这么长时间的磨难,我们的非本地生产VM存储全部由iSCSI提供,主要来自NetApp。
您可能要考虑ZFS ARC的3年以上错误,该错误在使用ZFS跳入太深之前仍然存在。
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6522017
(这很讨厌,因为它也会超出虚拟机管理程序的VM限制!)