VMware VMFS5和LUN大小 – 多个较小的数据存储或一个大的数据存储？

你没有指定你有多less虚拟机，或者他们将要做什么。 即使没有这些信息，我也会避免为了块/性能，争用和灵活性的原因而制作一个大的LUN。

我会假设你将虚拟化服务器，而不是桌面，好吗？ 接下来，我将假设您将使用多个ESX / ESXi服务器来访问您的存储并使其由vCenter Server进行pipe理。

在决定LUN大小和VMFS数量时，您需要平衡多个因素：性能，configuration灵活性和资源利用率，同时受到基础架构支持的最大configuration的限制。

您可以通过1个VM到1个LUN / VMFS映射获得最佳性能。 在同一个VMFS上的机器之间没有竞争，没有locking争用，每个负载分离，一切正常。 问题在于你要pipe理不合理数量的LUN，可能达到最大限制，面临着VMFSresize和迁移的麻烦，资源利用不足（VMFS上的单个百分点可用空间加起来）不好pipe理。

另一个极端是一个大VMFS被指定来承载一切。 您将以这种方式获得最佳的资源利用率，而在VMFS Y处于空闲状态时，决定将VMFS X作为热点的位置和问题进行部署时，将没有任何问题。 成本将是综合performance。 为什么？ 由于locking。 当一个ESX正在写入一个给定的VMFS时，其他的被locking在完成IO所需的时间并且必须重试。 这会降低性能。 在操场/testing和开发环境之外，存储configuration是错误的。

公认的做法是创build足够大的数据存储来托pipe多个VM，并将可用存储空间划分为适当大小的块。 虚拟机的数量取决于虚拟机。 您可能需要在VMFS上安装一个或几个关键的生产数据库，但是可以将三到四十个testing和开发机器安装到同一个数据存储上。 每个数据存储的虚拟机数量还取决于您的硬件（磁盘大小，rpm，控制器caching等）和访问模式（对于任何给定的性能级别，您可以在相同的VMFS上托pipe比邮件服务器多得多的Web服务器）。

较小的数据存储还有一个优点：它们阻止您在物理上阻塞每个数据存储太多的虚拟机。 没有太多的pipe理压力能够适应半TB容量的额外TB的虚拟磁盘（至less在他们听说精简configuration和重复数据删除之前）。

还有一件事：创build这些数据存储时，在单个块大小上进行标准化。 它稍后简化了很多事情，当你想在数据存储上做一些事情，并看到丑陋的“不兼容”的错误。

更新 ：DS3k将具有主动/被动控制器（即，任何给定的LUN都可以由控制器A或B提供服务，通过非拥有的控制器访问LUN会导致性能降低），因此它将支付偶数的LUN ，在控制器之间均匀分布。

我可以想象，从15个虚拟机/ LUN开始，空间增长到20个左右。

你的问题的简短答案是：这一切都取决于你的IO模式，这将是唯一的你的环境。

我build议你看看http://www.yellow-bricks.com/2011/07/29/vmfs-5-lun-sizing/，因为这可能会帮助你考虑你预期的IOPS和多less个LUNS可能是合适的。 也就是说，如果你不小心犯了错误，那么有些人会build议拥有许多LUN（如果我对前一个答案的更正得到批准，请参阅我对arrays端的LUN IO队列的评论）。 我倾向于同意，但是会走得更远，然后将它们集中到一个/几个VMFS卷（不相信有关扩展的FUD和其他VMFS限制http://virtualgeek.typepad.com/virtual_geek/2009/03 /vmfs-best-practices-and-counter-fud.html ）。 这将有利于pipe理vSphere中的单个/几个数据存储，并且由于vSphere会在每个扩展的第一个块开始时自动平衡可用扩展上的VM，因此将性能优势分散到多个LUN上。

还有其他的东西要考虑……你说没有一个虚拟机是特别的IO密集型的。 鉴于此，您可以考虑将RAID5和RAID10组合起来，以获得两全其美（空间和速度）的最佳效果。

此外，如果您的VMconfiguration了多个VMDK，并且操作系统和应用程序IO模式分布在这些虚拟磁盘上（即OS，Web，DB，日志等分别位于单独的VMDK上），则可以find每个VMDK一个不同的数据存储区以匹配该物理LUN的IOfunction（例如，RAID5上的操作系统，RAID10上的日志）。 它的所有关于保持相似的IO模式一起利用底层磁盘的机械行为，例如，日志写入一个虚拟机不会影响您在另一个虚拟机的Web读取率。

仅供参考…您可以成功虚拟化数据库服务器，您只需分析IO模式和IOPS率并将该IO定位到合适的LUN; 一直在意识到该LUN已经在做的IO模式和IOPS。 这就是为什么许多pipe理员将虚拟化归咎于糟糕的数据库性能……因为他们没有仔细计算多个服务器将它们放在共享LUN上时产生的IO / IOPS（即pipe理员的错误，而不是虚拟化的错误）。

每个卷（LUN）都有自己的队列深度，所以为了避免IO争用，很多实现使用更小的LUN。 也就是说，您可以非常容易地创build一个数据存储区跨度LUN。 就我所知，VMWare数据存储量更大（更less）的缺点是，您可能会遇到可同时启动的虚拟机数量的限制。

另一个考虑是控制器性能。 我不太了解你的SAN，但是即使不是所有的SAN，大多数情况下也需要一个LUN由同一个控制器拥有。 您希望系统上有足够的LUN，以便在控制器之间平衡工作量。

例如，如果您只有一个LUN，则一次只能使用一个主动控制器。 另一个会坐下来，因为它无所事事。

如果您有两个LUN，但其中一个比另一个忙得多，那么您将同时使用两个控制器。 当您添加更多的LUN时，控制器可以更均匀地分担工作量。

给你的具体build议：

在性能要求方面，你的虚拟机都是相同的。 我会创build两个LUN，每个控制器一个。 开始在第一个LUN上放置虚拟机，随着虚拟机安置，测量您的I / O延迟和队列深度。不要使用第二个LUN。 继续填写LUN 1.您将达到您开始看到LUN已满的性能指标的一个点，或者将您的一半虚拟机迁移到该LUN，并且仍保持性能。

如果看到性能问题，我会从LUN 1中删除30％的虚拟机，然后将它们移动到LUN 2.然后开始以相同的方式填充LUN 2。 如果需要的话，转到LUN 3 …这有道理吗？ 这个想法是为了在一个给定的LUN上实现最大的虚拟机密度，同时为虚拟空间提供大约30％的开销。

我还会为任何重型虚拟机制作一对“高性能”LUN。 再次，每个控制器分担工作量。

根据你上面的解释，你应该罚款1个数据存储。 超过3个主机的60个虚拟主机并不差（20：1）。 但是，如果您的光纤交换机至less是8Gb交换机，那么至less在一台主机上可以实现财务上的可能性，我build议您将HBA升级到8Gb。

这就是说，我会做至less2，如果不是3数据存储arrays上。 每个主机1个数据存储，所有服务器访问其他的vMotion。 我不太了解IBMarrays; 对于EMC，我会为每个数据存储创build一个包含3个LUN的单个RAID10组。 通过这种设置，具有8Gb HBA的主机对于更高的I / O系统来说是非常好的select。

你可以做1个数据存储/服务器，有一些我自己做的实例，但是我只在特殊服务器上做SAN复制。 通过9台服务器pipe理87个不同的数据存储区，以便vMotion在设置时变得混乱！ 我的大部分虚拟机都在共享数据存储上，共有5-10个服务器，具体取决于他们需要多less空间。

最后一个音符。 如果在故障转移对/群集中有任何种类的服务器或负载均衡，则您将需要它们在不同的数据存储中。 您不希望数据存储失败，然后没有服务器。 不可否认，如果你失去arrays，你已经失去了一切，但这就是我们备份的原因，对吧？