我們經(jīng)常在FC存儲設(shè)計中常問的是：LUN多大合適，一個LUN能***支持多少個虛擬機(jī)?

　　在存儲擴(kuò)容時常見錯誤是，只注重滿足容量需求，而忽視了對性能的影響。我建議Storage Sizing需要在保證性能的前提下，再考慮容量、可用性、安全等其他方面。

　　一概念及性能指標(biāo)

　　上圖是一個SAN環(huán)境下虛擬機(jī)訪問存儲設(shè)計到的模塊，可以看到影響虛擬機(jī)性能的因素很多了。所以我們在設(shè)計存儲時要周到的考慮到各個模塊，是不是可能有瓶頸?

　　性能指標(biāo)：

　　Throughput

　　單位時間內(nèi)傳輸?shù)臄?shù)據(jù)量。往往以KBPS或MBPS來衡量。

　　Latency (響應(yīng)時間)

　　指完成一個IO請求所需要的時間。往往以milliseconds來衡量。

　　二存儲擴(kuò)展時考慮因素

　　SCSI Reservation

　　在vSphere 4.1 推出VAAI之前，的確SCSI Reservation需要特別注意。VAAI的Hardware AssistedLocking很大程度上避免了SCSI Reservation的問題。

　　那么，這是不是意味這我們就可以用一個很大的LUN，比如說64T, 然后在那個LUN上無限制的添加VM呢?

　　千萬別忘了人們往往忽視的隊列。

　　隊列 Queuing

　　從上圖可以看到從上到下的四層都有隊列。隊列中等待執(zhí)行的任務(wù)越長，意味著更長的響應(yīng)時間。

　　先拿ESXi主機(jī)這一層來說，LUN Queue Depth決定了在同一時間可以對某個LUN發(fā)起的ActiveCommand 數(shù)量。ESXi缺省值是32. 所有虛擬機(jī)發(fā)起的Active Commands的總數(shù)***不要持續(xù)超過LUN Queue Depth. 雖然LUN Queue Depth可以***增加到64，但一般還是建議使用缺省值。

　　比如有多個I/O intensive的虛擬機(jī)在同一個LUN的時候，需要考慮把部分虛擬機(jī)轉(zhuǎn)移到其他LUN以避免Active Commands的總數(shù)持續(xù)超過LUNQueue Depth，從而造成延時。

　　HBA這層也有隊列，通常4,000 commandsper port 或者更高。所以一般瓶頸不在HBA層。

　　具體怎么算一個VMFS Volume***支持的VM數(shù)，請參見下文。

　　http://www.yellow-bricks.com/2009/07/07/max-amount-of-vms-per-vmfs-volume/

　　不過該文***也提到了，公式僅僅是個參考。

　　三實踐

　　化太多時間精力想設(shè)計的很***，未免學(xué)究氣。不妨開始先嘗試一個很粗的計劃。然后看情況在實踐中調(diào)整。

　　·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

　　虛擬機(jī)本身的I/O行為時變化的，而且實際中出現(xiàn)的因素，有時在設(shè)計時不能考慮周全。

　　實際出現(xiàn)問題的時候，你可以用Storage vMotion轉(zhuǎn)移VM到其他不忙的LUN。你也可以用StorageDRS。

　　本文出自 “坐看云起” 博客，請務(wù)必保留此出處http://frankfan.blog.51cto.com/6402282/1202160

　　原創(chuàng)作品，允許轉(zhuǎn)載，轉(zhuǎn)載時請務(wù)必以超鏈接形式標(biāo)明文章 原始出處 、作者信息和本聲明。否則將追究法律責(zé)任。