本文摘自SearchStorage网站的发帖讨论。这个问题由用户RickLR提出讨论。他提出，在确定虚拟存储的合适的逻辑单元（logical unit size，LUN）的大小的时候，需要关心什么问题？有用户回应了他们的方法。Ziggy S说使用较小的LUN，但是有不足。而Alan McLachlan说事情没这么简单。后来我们请存储专家Brien Posey参与讨论。Brien Posey对创建大的LUN和多个小的LUN提出了他的观点。

RickLR的提问原文

在我们的IBMShark上，我可以在整个RAID集之上创建一个LUN，其在主机计算机上显示为一个磁盘，我还可以创建几个小的LUN并且在主机计算机上有几个磁盘。哪个做法更好？曾经有人告诉我，多个小的LUN要比一个大的LUN更好，因为多个小的LUN将允许更多的来自操作系统（OS）的并发I / O。

对于我们的带元数据卷的EMC Symmetrix产品，同问。

Ziggy S：小LUN的利弊

多个较小的LUN的优点在于你可以把它们分散在许多阵列组并且使用逻辑卷管理器（Logical Volume Manager，LVM）来创建卷组（串接或者RAID 0）。这将会给后端带来最佳的潜在性能。不过，这不是LUN的大小的问题。这是向多个阵列组分布I/O的能力的问题。在Shark上，我建议一个阵列组在同一RAID 0卷组的LUN数量不超过4个。

多个小的LUN的缺点在于消耗了内部地址。如果LUN的大小为2 GB，那么无论你使用哪种大小的物理磁盘，Shark的最大容量都是8 TB （4096 x 2 GB）。

Alan McLachlan：LUN和应用程序服务器负载问题

如果你接受Ziggy S的建议——“多个较小的LUN的优点在于你可以把它们分散在许多阵列组并且使用逻辑卷管理器（Logical Volume Manager，LVM）来创建卷组（串接或者RAID 0）。这将会给后端带来最佳的潜在性能。”——那么你给应用程序服务器造成更多的负载。大的LUN或者使用LVM来串接或条带化小的LUN哪个方法更好，将取决于与应用程序、服务器容量、子系统的缓存和RAID性能、主机OS文件系统管理特性等相关的一系列因素。结果发现因为你的主机在拖后腿而并没有被驱动到那种潜能的时候，你就不打算让后端获得更佳的潜在性能了。我不是说你错了，只是不一定那么简单。

如果你因为任何理由不得不运行LVM，那么它无论如何都将增加对所有I/O的处理，所以你也可能从中获得最佳效果。最终，服务器端的文件系统问题可以破坏区块I/O的特性，所以区块设备层的一点点额外的开销也会变成有争议的（在这种情况下你也可能是对的）。

Posey Brien：LUN的大小应该由需求决定

哪种LUN的大小是最合适的问题一直争论激烈。正因为如此，我有言在先，不存在放之四海而皆准的理想的LUN的大小。每个人的需求不同，所以重要的是选择满足你的独特需求的LUN的大小，而不是坚持盲目的标准。

在选择LUN的大小的时候，有许多必须考虑的因素。这个清单并非包罗万象，但是它会给你一些要去思考的东西。

首先，你希望LUN被如何使用？例如，如果你需要大量的文件存储空间，那么创建一个LUN可能是合适的。同样地，我也碰到过一台存储阵列被配置成单个LUN然后被作为一个大的集群共享卷的情形。

当我谈到LUN将如何使用的时候，重要的是考虑已经被软件厂商落实的经过验证的最佳实践。举一个更具体的例子，假设你使用LUN来存放虚拟硬盘（virtual hard disk， VHD）。有些虚拟机管理程序供应商建议限制每个LUN的活动VHD的数量（不计算静态的、未被使用的VHD）。

支持创建多个小的LUN的最好的论据之一是备份和恢复。设想一下，一个LUN出现了问题并且需要重建和恢复。还原小的LUN要比还原大的LUN（假设两者都几乎用满）快的多，这是不言而喻的。

最后一个考虑因素是负载均衡。设想你有一台打算用于虚拟机（VM）存储的32 TB的存储阵列。你划分可用的存储有很多选择。你可以创建一个32 TB的LUN、两个16 TB的LUN或者4个8 TB的 LUN。你甚至可以创建32个1 TB的LUN。

如果你创建一个LUN，存储性能可能会下降，因为越来越多的VM被创建。在VMware的环境中，你可以通过使用Storage DRS对VM的工作负载进行负载均衡。然而，Storage DRS需要多个源数据存储（source datastore）。你可用的源数据存储越多，Storage DRS就有更多的选择来均衡工作负载。即便如此，在这种情况下你也可能不打算创建32个LUN，因为单个VM的大小很容易就超过1 TB。正因为如此，你必须根据虚拟机的大小来评估负载均衡的需求。