我们经常在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。
本文出自 “坐看云起” 博客，请务必保留此出处http://frankfan.blog.51cto.com/6402282/1202160
原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。
