由于 VMFS5 不再具有 VMFS 卷 2TB 的限制，我正在考虑哪种方案总体上更有利：-
- 较少的较大 LUN，或
- 更多较小尺寸的 LUN。
就我而言，我有一个新的 24 磁盘存储阵列，磁盘大小为 600GB。我将使用 RAID10，因此大约有 7.2TB，并尝试决定是使用 1 个大型 7TB 数据存储，还是使用多个各 1TB 的存储。
每种方法的优缺点是什么？
更新：当然，我在计算中忽略了热备件，所以它会略低于 7.2TB，但总体思路是一样的。:-)
更新 2：有 60 台虚拟机和 3 台主机。我们的虚拟机都不是特别 I/O 密集型的。它们大多数是 Web/应用服务器，还有监控（munin/nagios）、2 个负载最小的 Windows DC 等。除非数据库服务器的 I/O 要求非常低，否则它们很少被虚拟化。目前我认为我们唯一的虚拟数据库服务器是 MSSQL 盒，该盒上的数据库小于 1GB。
更新 3：有关阵列和 FC 连接的更多信息。阵列是 IBM DS3524，2 个控制器，每个控制器有 2GB 缓存。每个控制器有 4 个 8Gbit FC 端口。每个 ESXi 主机有 2 个 4Gbit FC HBA。
答案1
您没有指定您有多少台虚拟机或它们将要做什么。即使没有这些信息，出于块大小/性能、争用和灵活性的原因，我也会避免制作一个大 LUN。
答案2
我假设您要虚拟化服务器，而不是桌面，好吗？接下来，我假设您要使用多个 ESX/ESXi 服务器来访问您的存储，并让 vCenter Server 对其进行管理。
在决定 LUN 大小和 VMFS 数量时，您需要平衡几个因素：性能、配置灵活性和资源利用率，同时受基础架构支持的最大配置的约束。
您可以通过 1 VM 到 1 LUN/VMFS 映射获得最佳性能。同一 VMFS 上的机器之间没有竞争，没有锁定争用，每个负载都是分开的，一切都很好。问题是您将管理大量 LUN，可能达到支持的最大限制，面临 VMFS 大小调整和迁移的麻烦，资源利用不足（VMFS 上单个百分点的可用空间加起来），并且通常会造成难以管理的事情。
另一个极端是指定一个大型 VMFS 来托管所有内容。这样，您将获得最佳的资源利用率，不会出现决定在哪里部署什么的问题，也不会出现 VMFS X 成为热点而 VMFS Y 处于空闲状态的问题。成本将是总体性能。为什么？因为锁定。当一个 ESX 正在写入给定的 VMFS 时，其他 ESX 将被锁定以完成 IO 并必须重试。这会降低性能。在操场/测试和开发环境之外，这是错误的存储配置方法。
公认的做法是创建足够大的数据存储区来托管多个虚拟机，并将可用存储空间划分为适当大小的块。虚拟机的数量取决于虚拟机。您可能希望在 VMFS 上有一个或几个关键生产数据库，但允许三四十台测试和开发机器进入同一个数据存储区。每个数据存储区的虚拟机数量还取决于您的硬件（磁盘大小、rpm、控制器缓存等）和访问模式（对于任何给定的性能级别，您可以在同一个 VMFS 上托管比邮件服务器多得多的 Web 服务器）。
较小的数据存储区还有一个优势：它们可以防止您在每个数据存储区中物理塞入过多的虚拟机。无论管理压力有多大，都无法在半兆兆字节的存储上容纳额外的 1 兆字节虚拟磁盘（至少在他们听说精简配置和重复数据删除之前）。
还有一件事：创建这些数据存储时，请将单个块大小标准化。当您想要跨数据存储执行某些操作并看到难看的“不兼容”错误时，这会简化很多事情。
更新：DS3k 将具有主动/被动控制器（即，任何给定的 LUN 都可以由控制器 A 或 B 提供服务，通过非拥有的控制器访问 LUN 会导致性能下降），因此，在控制器之间均匀分布偶数个 LUN 是有好处的。
我可以想象从 15 个 VM/LUN 开始，然后逐渐增加到 20 个左右。
答案3
对你的问题的简短回答是：这完全取决于你的 IO 模式，并且这对于你的环境来说是独一无二的。
我建议你看看这里http://www.yellow-bricks.com/2011/07/29/vmfs-5-lun-sizing/因为这可能有助于您考虑预期的 IOPS 以及多少个 LUNS 可能合适。也就是说，如果您要谨慎行事，有些人会建议拥有许多 LUNS（如果我对之前答案的更正被批准，请参阅我关于阵列端的 LUN IO 队列的评论）。我倾向于同意，但会更进一步将它们一起扩展到单个/几个 VMFS 卷中（不要相信有关扩展和其他 VMFS 限制的 FUDhttp://virtualgeek.typepad.com/virtual_geek/2009/03/vmfs-best-practices-and-counter-fud.html）。这将有利于在 vSphere 中管理单个/几个数据存储，并且由于 vSphere 会从每个范围的第一个块开始自动平衡可用范围上的虚拟机，因此性能优势会将您的 IO 分散到多个 LUN 上。
还有一点需要考虑...您说没有一个虚拟机特别需要 IO。鉴于此，您可能想考虑 RAID5 和 RAID10 的组合，以获得两全其美的效果（空间和速度）。
此外，如果您的虚拟机配置了多个 VMDK，操作系统和应用程序 IO 模式分布在这些虚拟磁盘上（即操作系统、Web、DB、日志等分别位于单独的 VMDK 上），那么您可以将每个 VMDK 定位在不同的数据存储上，以匹配该物理 LUN 的 IO 能力（例如，操作系统位于 RAID5 上，日志位于 RAID10 上）。这一切都是为了将类似的 IO 模式保持在一起，以利用底层磁盘的机械行为，例如，一个虚拟机中的日志写入不会影响另一个虚拟机中的 Web 读取速率。
仅供参考...你能成功虚拟化数据库服务器，您只需分析 IO 模式和 IOPS 速率，并将该 IO 定位到合适的 LUN；同时注意该 LUN 已经在执行的 IO 模式和 IOPS。这就是为什么许多管理员将数据库性能不佳归咎于虚拟化的原因……因为他们没有仔细计算多台服务器产生的IO/IOPS他们将它们放在共享 LUN 上（即，这是管理员的错误，而不是虚拟化的错误）。
答案4
另一个考虑因素是控制器性能。我不清楚您的 SAN 具体情况，但大多数（如果不是全部）SAN 都要求一个 LUN 一次由一个控制器拥有。您希望系统上有足够的 LUN，以便能够在控制器之间平衡工作负载。
例如，如果您只有一个 LUN，则您每次只能使用一个活动控制器。另一个控制器将处于闲置状态，因为它无事可做。
如果您有两个 LUN，但其中一个比另一个繁忙得多，那么您将同时使用两个控制器，但使用量并不均衡。随着您添加更多 LUN，控制器将更均匀地分担工作负载。
给您的具体建议：
就性能要求而言，您的虚拟机都相对相同。我会创建两个 LUN，每个控制器一个。开始将虚拟机放在第一个 LUN 上，并在虚拟机稳定下来后随时间测量 I/O 延迟和队列深度。暂时不要使用第二个 LUN。继续填充 LUN 1。您要么会达到开始看到 LUN 已满的性能指标的点，要么会将一半的虚拟机迁移到该 LUN，并且仍能保持性能。
如果您确实发现性能问题，我会从 LUN 1 中删除 30% 的虚拟机并将其移至 LUN 2。然后以相同的方式开始填充 LUN 2。如有必要，转到 LUN 3...这有意义吗？这个想法是在给定的 LUN 上实现最大虚拟机密度，同时为缓冲空间增加大约 30% 的开销。
我还会为任何高负载虚拟机创建一对“高性能”LUN。同样，每个控制器一个，以分担工作负载。