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