作者：范军 （Frank Fan） 新浪微博：@frankfan7   微信：frankfan7

我们经常在FC存储设计中常问的是：LUN多大合适，一个LUN能最大支持多少个虚拟机？

在存储扩容时常见错误是，只注重满足容量需求，而忽视了对性能的影响。我建议Storage Sizing需要在保证性能的前提下，再考虑容量、可用性、安全等其他方面。

一概念及性能指标

上图是一个SAN环境下虚拟机访问存储设计到的模块，可以看到影响虚拟机性能的因素很多了。所以我们在设计存储时要周到的考虑到各个模块，是不是可能有瓶颈？

性能指标：

Throughput

单位时间内传输的数据量。往往以KBPS或MBPS来衡量。

Latency (响应时间)

指完成一个IO请求所需要的时间。往往以milliseconds来衡量。

二存储扩展时考虑因素

SCSI Reservation

在vSphere 4.1 推出VAAI之前，的确SCSI Reservation需要特别注意。VAAI的Hardware AssistedLocking很大程度上避免了SCSI Reservation的问题。

那么，这是不是意味这我们就可以用一个很大的LUN，比如说64T, 然后在那个LUN上无限制的添加VM呢？

千万别忘了人们往往忽视的队列。

队列  Queuing

从上图可以看到从上到下的四层都有队列。队列中等待执行的任务越长，意味着更长的响应时间。

先拿ESXi主机这一层来说，LUN Queue Depth决定了在同一时间可以对某个LUN发起的ActiveCommand 数量。ESXi缺省值是32. 所有虚拟机发起的Active Commands的总数最好不要持续超过.     虽然LUN Queue Depth可以最大增加到64，但一般还是建议使用缺省值。

比如有多个I/O intensive的虚拟机在同一个LUN的时候，需要考虑把部分虚拟机转移到其他LUN以避免Active Commands的总数持续超过LUNQueue Depth，从而造成延时。

HBA这层也有队列，通常4,000 commandsper port 或者更高。所以一般瓶颈不在HBA层。

具体怎么算一个VMFS Volume最大支持的VM数，请参见下文。

不过该文最后也提到了，公式仅仅是个参考。

三实践

化太多时间精力想设计的很完美，未免学究气。不妨开始先尝试一个很粗的计划。然后看情况在实践中调整。

·10 high I/O VMs perdatastore

·15 average I/O VMs perdatastore

·20 low I/O VMs perdatastore

上述建议来自

虚拟机本身的I/O行为时变化的，而且实际中出现的因素，有时在设计时不能考虑周全。

实际出现问题的时候，你可以用Storage vMotion转移VM到其他不忙的LUN。你也可以用StorageDRS。