虚拟机队列实战虚拟化存储设计之LUN Sizing

每日一贴,今天的内容关键字为虚拟机队列

    作者：范军 （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.     虽然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。

    

文章结束给大家分享下程序员的一些笑话语录： 姿势要丰富，经常上百度！