实战虚拟化存储设计之二LUN Sizing

我们经常在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. 虽然LUN Queue Depth可以最大增加到64，但一般还是建议使用缺省值。
比如有多个I/O intensive的虚拟机在同一个LUN的时候，需要考虑把部分虚拟机转移到其他LUN以避免Active Commands的总数持续超过LUNQueue Depth，从而造成延时。
HBA这层也有队列，通常4,000 commandsper port 或者更高。所以一般瓶颈不在HBA层。
具体怎么算一个VMFS Volume最大支持的VM数，请参见下文。 http://www.yellow-bricks.com/2009/07/07/max-amount-of-vms-per-vmfs-volume/ 不过该文最后也提到了，公式仅仅是个参考。
三实践
化太多时间精力想设计的很完美，未免学究气。不妨开始先尝试一个很粗的计划。然后看情况在实践中调整。
·10 high I/O VMs perdatastore
·15 average I/O VMs perdatastore
·20 low I/O VMs perdatastore
上述建议来自VAAIand the Unlimited VMs per Datastore Urban Myth
虚拟机本身的I/O行为时变化的，而且实际中出现的因素，有时在设计时不能考虑周全。
实际出现问题的时候，你可以用Storage vMotion转移VM到其他不忙的LUN。你也可以用StorageDRS。