我們經常在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

　　原創作品，允許轉載，轉載時請務必以超鏈接形式標明文章 原始出處 、作者信息和本聲明。否則將追究法律責任。