为数百个 VM Web 服务器选择 SAN 技术

Sim*_*een 15 virtualization storage storage-area-network nfs vmware-vsphere

问题

我们在现有平台上的性能存在问题,所以我正在转向蜂巢思维,以寻求对此的第二意见。到目前为止,性能问题与 IOPS 而不是吞吐量有关。

情景

由 16 台主机组成的刀片中心,每台主机具有 64GB 的 RAM。(它是带有 M610 的 Dell M1000e,但这可能无关紧要)500 台虚拟机、所有 Web 服务器(或相关的 Web 技术,例如 MySQL、负载平衡器等),大约 90% 是 Linux,其余为 Windows。管理程序是 VMWare vSphere。我们需要提供主机HA,所以本地存储用完了。因此,主机只需一张 SD 卡即可启动。

一点背景思考

目前,我们有多达 6 台主机(刀片中心将在一年内以目前的增长达到满负荷),并且我们正在将 iSCSI 运行到带有 MD1220 的 Dell MD3220i 以进行扩展。

我们考虑过的可能选项,以及随之而来的即时想法:

  • 将 VM 分布在 NFS 数据存储中,并运行 NFS 存储以满足最多给定数量的 VM 的性能要求。NFS 的扩展性似乎更便宜,并且比块级存储更抽象,因此我们可以根据需要移动它。
  • 添加更多 MD3220i 控制器/目标。我们担心这样做可能会对 VMWare 处理大量目标的方式产生负面影响。
  • 将所有磁盘从 Nearline SAS 交换到 SSD。这应该完全解决 IOPS 问题,但有明显的副作用,即削减我们的存储容量。而且它仍然非常昂贵。
  • vSphere 5 有一个存储设备。我们还没有研究这么多,但它一定很好用吗?

问题

你会在所有这些之下运行什么样的存储?它不需要扩展到另一个刀片中心,它只需要为所有这些 VM 提供相对良好的性能。

我不是在寻找“购买 SAN x 因为它是最好的”的答案。我正在寻找关于各种 SAN 技术(iSCSI、FC、FCoE、InfiniBand、NFS 等)、不同类型的存储(SATA、SAS、SSD)以及处理 100 多个 VM 的存储的方法(整合、分离)的想法、分片等)。

绝对欢迎任何想法,链接,指南,指针等。我也很想听听关于我们已经考虑过的上述选项的想法。

非常感谢您提供任何输入!

12 年 3 月 5 日更新

到目前为止一些精彩的回复,非常感谢大家!

到目前为止对这个问题的回答,我开始认为以下路线是这样的:

  • 将可用存储分层到 VMWare 集群,并将 VM 磁盘放置在适合其工作负载的存储上。
  • 潜在地使用能够自动管理数据放置到合适存储的 SAN。
  • Infiniband 看起来是在主机满负荷的情况下获得所需带宽的最具成本效益的方法。

听起来绝对值得利用主要 SAN 供应商的售前服务来了解他们的情况。

我将继续考虑这个问题一段时间。同时,感谢收到任何更多的建议!

Bas*_*sil 13

一个好的 VMWare 存储平台的关键是了解 VMWare 产生什么样的负载。

  • 首先,由于您托管了大量服务器,因此工作负载通常是随机的。同时进行的 IO 流很多,能够成功预缓存的并不多。
  • 其次,它是可变的。在正常操作期间,您可能会看到 70% 的随机读取,但是当您决定将虚拟机移动到新的数据存储或其他地方时,您将看到 60GB 的大量顺序写入。如果您不注意架构,这可能会削弱您的存储处理正常 IO 的能力。
  • 第三,您环境的一小部分通常会产生很大一部分存储工作负载。

为 VMWare 平台构建存储的最佳方法是从基础开始。

  • 您需要能够为大量随机读取工作负载提供服务,这意味着更小更快的驱动器,以及可能的 SSD。大多数现代存储系统允许您根据访问方式自动移动数据。如果您打算使用 SSD,您要确保这就是您使用它的方式。它应该作为逐渐减少热点的一种方式。无论您是否使用 SSD,能够将所有工作放在所有驱动器上都是有益的,因此具有某种类型的存储池的东西将是有益的。
  • 您需要能够为间歇性大写操作提供服务,它不太关心底层驱动器的主轴速度,但确实关心控制器堆栈的效率和缓存的大小。如果您有镜像缓存(这不是可选的,除非您愿意在控制器出现故障时返回备份),用于镜像的两个缓存之间的带宽通常将成为大型顺序写入的瓶颈。确保您获得的任何内容都具有用于写入缓存的高速控制器(或集群)互连。尽最大努力获得具有尽可能多端口的高速前端网络,同时在价格上保持现实。良好前端性能的关键是将您的存储负载放在尽可能多的前端资源上。
  • 您可以通过为低优先级存储和精简配置设置一个层来大幅降低成本。如果您的系统没有自动将单个块迁移到便宜的大/慢驱动器(如近线 SAS 或 7200 RPM 和 2TB+ 大小的 SATA),请尝试手动执行此操作。大型慢速驱动器是存档、备份、某些文件系统甚至使用率较低的服务器的绝佳目标。
  • 坚持存储是 VAAI 集成的,以便 VMWare 可以取消分配 VM 以及数据存储的未使用部分。


eww*_*ite 10

我的大型 VMWare 部署是超过 10GbE 的 NFS 和 iSCSI。这意味着服务器中的双端口 10GbE HBA 以及存储头。为此,我非常喜欢基于 ZFS 的存储。在我的情况下,它围绕着商业NexentaStor,但有些人选择推出自己的。

在这种情况下,基于 ZFS 的存储的关键特性是 ARC/L2ARC 缓存功能,允许您对存储进行分层。最活跃的数据将在 RAM 和 SSD 存储中作为第二层找到。使用 10k 或 15k SAS 驱动器运行您的主存储池也将是有益的。

这是分析和了解您的工作负载的另一个案例。与可以分析您的存储模式并帮助您计划的人一起工作。在 ZFS/NexentaStor 方面,我喜欢PogoStorage。如果没有这种洞察力,传输方法(FC、FCoE、iSCSI、NFS)可能无关紧要。您是否对现有基础设施进行了任何监控?I/O 活动现在是什么样的?

  • 啊,我刚刚阅读了 ZFS 和 ARC/L2ARC。那是很棒的酱汁:) (2认同)

wom*_*ble 8

关键问题是:“瓶颈在哪里?” 您提到了 IOPS,但这是否意味着您肯定将磁盘本身确定为瓶颈,或者仅仅是 SAN 端口未满负荷运行,或者 VM 的 iowait 比您想要的要多得多?

如果您确定磁盘是限制因素,那么切换到 NFS 或 infiniband 或任何不会对您的性能产​​生影响的东西——您需要 SSD(或至少混合 SSD 的分层存储)或一整捆更多的主轴(自从世界的步进电机生产被冲入大海以来,该解决方案最近本身变得更加昂贵)。

但是,如果您不能 100% 确定瓶颈实际在哪里,那么您需要先找到它——根据其他人的猜测或多或少地随机更换部分存储基础设施是不可能的非常有效(特别是考虑到实施任何更改的成本很高)。

  • “我总是假设发布问题的人已经完成了他们的功课”——baaaaaad 假设...... (4认同)