技術(shù)報(bào)告netappvmware view席位性能

123內(nèi)容提 環(huán) 測(cè)試、方法和工 場(chǎng) 創(chuàng)123內(nèi)容提 環(huán) 測(cè)試、方法和工 場(chǎng) 創(chuàng)建測(cè) 啟動(dòng)測(cè) 登錄后執(zhí)行工作負(fù)載測(cè) 工 45最終用戶體 詳細(xì)測(cè)試結(jié) 創(chuàng)建進(jìn) 初始登 星期二早晨登 重新啟 星期一早晨登 穩(wěn)定狀 觀察結(jié)果和經(jīng)驗(yàn)總 6附 SSD和 應(yīng)用程序工作負(fù) 78參 致 表格表1)創(chuàng)建場(chǎng)景 表2)初始登錄場(chǎng)景 表3)“星期二早晨”或典型登錄場(chǎng)景 表4)啟動(dòng)場(chǎng)景 表5)“星期一早晨”或配置文件加載登錄場(chǎng)景 表6)穩(wěn)定狀態(tài)場(chǎng)景 表7)AcmeCorporation日歷 表8)初始登錄的用戶體驗(yàn)（以秒為單位） 表9)初始登錄用戶體驗(yàn)（“好”、“一般”和“差”登錄時(shí)間的百分比） 表10)初始登錄期間DataONTAP8.0.1與8.1的對(duì)比結(jié)果 表11)初始登錄時(shí)的I/O并發(fā)數(shù)、速率以及讀取和寫(xiě)入操作大小 2表12)星表12)星期二早晨登錄的用戶體驗(yàn)（以秒為單位） 表13)星期二早晨登錄用戶體驗(yàn)（“好”、“一般”和“差”登錄時(shí)間的百分比） 表14)星期二早晨登錄期間DataONTAP8.0.1與8.1的對(duì)比結(jié)果 表15)星期二早晨登錄時(shí)的I/O并發(fā)數(shù)、速率以及讀取和寫(xiě)入操作大小 表16)重新啟動(dòng)期間DataONTAP8.0.1與8.1的對(duì)比結(jié)果 表17)星期一早晨登錄的用戶體驗(yàn)（以秒為單位） 表18)星期一早晨登錄的用戶體驗(yàn)（“好”、“一般”和“差”登錄時(shí)間的百分比） 表19)星期一早晨登錄期間DataONTAP8.0.1與8.1的對(duì)比結(jié)果 表20)星期一早晨登錄時(shí)的I/O并發(fā)數(shù)、速率以及讀取和寫(xiě)入操作大小 插圖圖1)每秒讀取和寫(xiě)入操作數(shù) 圖2)讀取和寫(xiě)入吞吐量 圖3)啟動(dòng)時(shí)的讀取操作細(xì)分 圖4)初始登錄時(shí)的讀取操作細(xì)分 圖5)穩(wěn)定狀態(tài)時(shí)的讀取操作細(xì)分 圖6)“半POD”架構(gòu) 圖7)RAWC屏幕，顯示登錄后執(zhí)行工作負(fù)載場(chǎng)景 圖8)Stratusphere（圖片由LiquidwareLabs提供） 圖9)顯示機(jī)器體驗(yàn)指標(biāo)的VDIUX配置文件屏幕 圖10)顯示I/O體驗(yàn)指標(biāo)的VDIUX配置文件屏幕 圖11)克隆虛擬桌面各階段花費(fèi)時(shí)間細(xì)分 圖12)初始登錄時(shí)的讀取和寫(xiě)入吞吐量 圖13)初始登錄時(shí)的每秒讀取和寫(xiě)入操作數(shù) 圖14)初始登錄中的讀取/寫(xiě)入?yún)f(xié)議延遲 圖15)初始登錄時(shí)的讀取和寫(xiě)入延遲 圖16)初始登錄時(shí)的CPU利用率 圖17)初始登錄時(shí)的讀取操作細(xì)分 圖18)初始登錄時(shí)的讀取和寫(xiě)入操作大小 圖19)星期二早晨登錄的讀取和寫(xiě)入吞吐量 圖20)星期二早晨登錄時(shí)的每秒讀取和寫(xiě)入操作數(shù) 圖21)星期二早晨登錄的讀取和寫(xiě)入?yún)f(xié)議延遲 圖22)星期二早晨登錄的讀取和寫(xiě)入延遲 圖23)星期二早晨登錄的CPU利用率 圖24)星期二早晨登錄的讀取操作細(xì)分 圖25)星期二早晨登錄的讀取和寫(xiě)入操作大小 3圖圖26)啟動(dòng)時(shí)的讀取和寫(xiě)入吞吐量 圖27)啟動(dòng)時(shí)的每秒讀取和寫(xiě)入操作數(shù) 圖28)啟動(dòng)時(shí)的讀取和寫(xiě)入?yún)f(xié)議延遲 圖29)啟動(dòng)期間的CPU利用率 圖30)啟動(dòng)時(shí)的讀取操作細(xì)分 圖31)星期一早晨登錄的讀取和寫(xiě)入吞吐量 圖32)星期一早晨登錄的每秒讀取和寫(xiě)入操作數(shù) 圖33)星期一早晨登錄的讀取和寫(xiě)入延遲（以秒為單位） 圖34)星期一早晨登錄的來(lái)賓操作系統(tǒng)讀取和寫(xiě)入延遲 圖35)星期一早晨登錄的CPU利用率 圖36)星期一早晨登錄的讀取操作細(xì)分 圖37)星期一早晨登錄的讀取和寫(xiě)入操作大小 圖38)滴水工作負(fù)載（每秒操作數(shù)） 圖39)滴水工作負(fù)載（每秒MB） 圖40)顯示“滴水效應(yīng)”工作負(fù)載的屏幕 圖41)啟動(dòng)時(shí)間對(duì)比（按驅(qū)動(dòng)器類(lèi)型） 圖42)使用SATA驅(qū)動(dòng)器的用戶的初始登錄體驗(yàn) 圖43)使用SATA驅(qū)動(dòng)器的用戶在星期一早晨的體驗(yàn) 圖44)首次打開(kāi)和關(guān)閉MicrosoftWord時(shí)的讀取操作數(shù) 圖45)首次打開(kāi)和關(guān)閉MicrosoftWord時(shí)的寫(xiě)入操作數(shù) 圖46)后續(xù)打開(kāi)和關(guān)閉MicrosoftWord時(shí)的讀取操作數(shù) 圖47)后續(xù)打開(kāi)和關(guān)閉MicrosoftWord時(shí)的寫(xiě)入操作數(shù) 圖48)首次打開(kāi)WindowsMediaPlayer并播放影片時(shí)的讀取操作數(shù) 圖49)首次打開(kāi)WindowsMediaPlayer并播放影片時(shí)的寫(xiě)入操作數(shù) 圖50)后續(xù)打開(kāi)WindowsMediaPlayer并播放影片時(shí)的讀取操作數(shù) 圖51)后續(xù)打開(kāi)WindowsMediaPlayer并播放影片時(shí)的寫(xiě)入操作數(shù) 圖52)保存Excel工作簿時(shí)的讀取操作數(shù) 圖53)保存Excel工作簿時(shí)的寫(xiě)入操作數(shù) 4 內(nèi)容提20108月，NetApp聯(lián)合若干合作伙 內(nèi)容提20108月，NetApp聯(lián)合若干合作伙伴共同發(fā)布了一份白皮書(shū)，其中介紹了如何部署使用NetApp存儲(chǔ)、CiscoUnifiedComputingSystem?(CiscoUCS?)、CiscoNexus?、VMware軟件和Fujitsu服務(wù)器的50,000席位虛擬桌面基礎(chǔ)架構(gòu)(VDI)環(huán)境。這份初始白皮書(shū)僅關(guān)注每個(gè)合作伙伴為支持此部署而提供的高級(jí)別的架構(gòu)設(shè)計(jì)和技術(shù)詳情。根據(jù)在虛擬化基礎(chǔ)架構(gòu)中部署5,000席位的硬件和軟件需求，最初需要使用NetAppFAS3170存儲(chǔ)控制器，以及界定好的模塊化存儲(chǔ)單元和服務(wù)器（稱(chēng)為“桌面池”[POD]）。初始白皮書(shū)將POD定義如下：60ESX?4.1主機(jī)（CiscoUCSFujitsu1FAS3170A高可用性(HA)集9615KRPM光纖通道驅(qū)動(dòng)2512GB閃存VMwarevCenter?個(gè)運(yùn)行PC-over-IP(PCoIP)連接協(xié)議的VMwareView?ConnectionServer5,000個(gè)Microsoft?Windows?7虛擬桌面虛擬機(jī)(VM)發(fā)布初始白皮書(shū)后不久，NetApp便更新了其中端存儲(chǔ)產(chǎn)品，用FAS3270存儲(chǔ)系統(tǒng)取代初始白皮書(shū)中使用的FAS3170存儲(chǔ)系統(tǒng)，提高了容量和性能。因此，在本技術(shù)報(bào)告所述的測(cè)試中，我們使用FAS3270存儲(chǔ)系統(tǒng)而不是初始白皮書(shū)中所用的FAS3170（因?yàn)镕AS3270顯著提升了解決方案的性能和可擴(kuò)展性）。除此之外，后續(xù)的早期測(cè)試也表明：要想能夠有效支持5,000個(gè)VDI桌面，需要我們?cè)偬砑?0臺(tái)服務(wù)器，以保證測(cè)試期間有充足的內(nèi)存資源。因此，我們現(xiàn)在將POD定義如下：90ESX4.1服務(wù)器2個(gè)具有超線程功能的四核心NehalemCPUFujitsuPRIMERGYRX200-48GB主內(nèi)1FAS3270AHA集9615KRPM光纖通道驅(qū)動(dòng)2512GB閃存模2VMwarevCenter3個(gè)運(yùn)PC-over-IP(PCoIP)連接協(xié)議的VMwareViewConnection5,000個(gè)MicrosoftWindows7虛擬桌面根據(jù)這一新定義，每個(gè)NetAppFAS3270控制器支持45ESX服務(wù)器和2,500Windows7永久虛擬桌面。由于創(chuàng)建一個(gè)完整的POD需要滿足眾多硬件要求，因此我們決定對(duì)這些后續(xù)測(cè)試作出限制：使用相當(dāng)于二分之一個(gè)POD所要求的上述硬件，或者使用由兩個(gè)FAS3270存儲(chǔ)控制器中的一個(gè)提供服務(wù)的2,500個(gè)虛擬桌面。由于每個(gè)FAS3270存儲(chǔ)控制器實(shí)際上獨(dú)立服務(wù)于2,500個(gè)虛擬桌面，因此針對(duì)2,500個(gè)虛擬桌面衡量得到的性能直接加倍，就能得到支持5,000個(gè)虛擬桌面的完整POD的性能在這些測(cè)試中，我們使用VMwareView4.5和VMwarevSphere4.1部署由2,500個(gè)虛擬桌面組成的場(chǎng)景。除此之外，我們還使用VMwareReferenceArchitectureWorkloadCode(RAWC)工具生成VDI我們針對(duì)最新的公開(kāi)發(fā)布(GA)版本(DataONTAP?8.0.1)和DataONTAP8.1進(jìn)行測(cè)試。之所以選擇使用DataONTAP8.1，是因?yàn)樗苓M(jìn)一步提升NetApp虛擬存儲(chǔ)分層(VST)功能的性能，同時(shí)減少所需的磁盤(pán)軸數(shù)量。借助VST，客戶不僅可以從NetApp存儲(chǔ)效率中受益，而且還可以顯著提高I/O性能。DataONTAP操作系統(tǒng)本身內(nèi)置有VST，并且通過(guò)利用NetApp主存儲(chǔ)重復(fù)數(shù)據(jù)刪除和文件/卷FlexClone等塊共享技術(shù)應(yīng)用VST，可以減少所需的緩存量并消除重復(fù)磁盤(pán)讀取。對(duì)于任意重復(fù)塊，僅將一個(gè)實(shí)例讀入緩存，因而所需的緩存少于傳統(tǒng)存儲(chǔ)解決方案。由于使用節(jié)省空間的NetApp克隆技術(shù)，5VMeViw的實(shí)施最初可節(jié)省高達(dá)%的空間，這意味著更高的緩存重復(fù)數(shù)據(jù)刪除率和高緩存命中率。在處理并發(fā)系統(tǒng)啟動(dòng)（”）和登錄成百上千個(gè)虛擬桌面系統(tǒng)（可能導(dǎo)致傳統(tǒng)舊式存儲(chǔ)系統(tǒng)超負(fù)荷工作）VST特別有效。與以前版本的DtaVMeViw的實(shí)施最初可節(jié)省高達(dá)%的空間，這意味著更高的緩存重復(fù)數(shù)據(jù)刪除率和高緩存命中率。在處理并發(fā)系統(tǒng)啟動(dòng)（”）和登錄成百上千個(gè)虛擬桌面系統(tǒng)（可能導(dǎo)致傳統(tǒng)舊式存儲(chǔ)系統(tǒng)超負(fù)荷工作）VST特別有效。與以前版本的DtaAP.1版本可以更加高效地共享主內(nèi)存中經(jīng)過(guò)重復(fù)數(shù)據(jù)刪除的塊。這樣，存儲(chǔ)控制器的主內(nèi)存就可以處理更大型的工作集，從而加快訪問(wèn)速度并減少占用P。VDI工作負(fù)載遠(yuǎn)遠(yuǎn)超出了穩(wěn)定狀態(tài)下的工作負(fù)載。了解該階段的特征非常重要，但是在某些情況下重新啟動(dòng)、登錄、創(chuàng)建配置文件和操作大量虛擬桌面也會(huì)給支持整個(gè)VDI環(huán)境的存儲(chǔ)帶來(lái)沉重壓力。如果沒(méi)能理解和計(jì)劃這些工作負(fù)載，會(huì)對(duì)最終用戶體驗(yàn)和項(xiàng)目成功產(chǎn)生嚴(yán)重的負(fù)面影響。在本報(bào)告接下來(lái)的內(nèi)容中，我們將從Acmeopotion這個(gè)虛構(gòu)公司的視角查看一些不同的VDI常見(jiàn)場(chǎng)景。Acme已經(jīng)借助tApp存儲(chǔ)部署了,0VDIAcme希望了解在一個(gè)典型工作周內(nèi)可能遇到的不同類(lèi)型的工作負(fù)載（極具代表性的用戶大量登錄、啟動(dòng)和停止應(yīng)用程序，以及借助為其提供的應(yīng)用程序執(zhí)行日常任務(wù)）。另外，日常維護(hù)有時(shí)會(huì)要求關(guān)閉所有虛擬桌面，然后又需要同時(shí)打開(kāi)并啟動(dòng)大量VM。在表1到表6中，這些場(chǎng)景及結(jié)果都根據(jù)用戶體驗(yàn)進(jìn)行了衡量，并且從一個(gè)較高的水平進(jìn)行了定義。在整個(gè)報(bào)告中，用戶體驗(yàn)均由LiquidwareLabsStratusphereUX使用加權(quán)算法確定是不是“好”。啟動(dòng)場(chǎng)景和創(chuàng)建場(chǎng)景的用戶體驗(yàn)用啟動(dòng)和創(chuàng)建所用的時(shí)間來(lái)衡量。請(qǐng)注意，測(cè)試中選擇的是VMware建議的應(yīng)用程序混合，這些應(yīng)用程序產(chǎn)生的工作負(fù)載為：每秒的“有經(jīng)驗(yàn)用戶”的工作負(fù)載）次輸入/輸出操(IOPS)/桌面（即預(yù)期表1創(chuàng)建場(chǎng)2)初始登錄場(chǎng)表表3)星期二早6測(cè)成功的主要衡量標(biāo)用戶體2,500個(gè)用戶登錄以前訪問(wèn)的VM。登錄后，用戶開(kāi)LiquidwareLabsUX衡量的用戶DataONTAP8.0.1：100的用戶獲DataONTAP8.1：100的用戶獲得測(cè)成功的主要衡量標(biāo)用戶體2,500個(gè)用戶在半個(gè)小時(shí)之該登錄觸發(fā)2,500份配LiquidwareLabsUX衡量的用戶DataONTAP8.0.1：62的用戶獲得“好”用戶體驗(yàn)，38%的用戶獲得DataONTAP8.1：97的用戶獲得“好”用戶體驗(yàn)，3%的用戶獲得測(cè)成功的主要衡量標(biāo)創(chuàng)建時(shí)創(chuàng)建2,500VM并衡量花從克隆進(jìn)程開(kāi)始到準(zhǔn)備好啟動(dòng)2,500VM共花費(fèi)3個(gè)小表4啟動(dòng)場(chǎng) 5)“星期一早晨”或配置文件表4啟動(dòng)場(chǎng) 5)“星期一早晨”或配置文件加載登錄場(chǎng)景表6)穩(wěn)定狀態(tài)場(chǎng)我們?cè)跍y(cè)試中從一個(gè)較高的水平確定了每個(gè)場(chǎng)景均會(huì)生成各自獨(dú)特的工作負(fù)載。啟動(dòng)工作負(fù)載的特征是PS計(jì)數(shù)較高?！靶瞧谝辉绯俊眻?chǎng)景以及初始登錄場(chǎng)景生成的工作負(fù)載的讀取和寫(xiě)VM的啟動(dòng)通常不會(huì)影響最終用戶體驗(yàn)，但發(fā)生A、災(zāi)難恢復(fù)D)或任何計(jì)劃外維護(hù)之類(lèi)的事件時(shí)除外。在這種情況下，快速啟動(dòng)對(duì)最終用戶來(lái)說(shuō)尤為重要。在登錄時(shí)，無(wú)論是星期幾，用戶都不可能忍受等待5分鐘才能使用桌面。當(dāng)用戶使用自己的桌面時(shí)，他們希望自己桌面的性能能與物理桌面媲美，甚至超出物理桌面。如果不能正確了解這些不同工作負(fù)載的特征以及它們對(duì)基礎(chǔ)架構(gòu)和最終用戶的影響，最終將影響項(xiàng)目的成功。除此之外，我們發(fā)現(xiàn)這些不同類(lèi)別的工作負(fù)載體現(xiàn)出的特征有時(shí)會(huì)與常說(shuō)的VDI工作負(fù)載分類(lèi)（小塊磁盤(pán)寫(xiě)入塊通常很?。ㄒ话銥?KB），但也可能大很多；在大型文件保存操作期間曾有過(guò)1寫(xiě)入操作的記錄讀取操作的大小范圍從4KB以下到1024KB，同時(shí)隨機(jī)讀取和順序讀取在數(shù)量上較為均衡。換句話說(shuō)，盡管虛擬桌面工作負(fù)載確實(shí)會(huì)生成較小的隨機(jī)工作負(fù)載，但是它們也會(huì)生成較大的隨機(jī)操以及大小不一的順序操作。我們的測(cè)試顯示，VDI工作負(fù)載的行業(yè)標(biāo)準(zhǔn)定義（僅考慮IOPS）過(guò)于簡(jiǎn)單，正確定義VDI環(huán)境的存儲(chǔ)大小需要考慮更多方面。圖12中的圖表顯示文中所述場(chǎng)景之間的工作負(fù)載區(qū)別，它們可能在Acmeopotion的VDI環(huán)境生命周期中極具代表性的某天或某周發(fā)生（以“生命周期中的一天”格式顯示。在最初的,0席位VDI白皮書(shū)中，環(huán)境是使用頂尖技術(shù)構(gòu)建的。我們已對(duì)原始配置進(jìn)行測(cè)試，但是由于軟件和硬件進(jìn)行了多次修訂，因此對(duì)新版本也進(jìn)行了測(cè)試。盡管原始測(cè)試的結(jié)果已驗(yàn)證了架構(gòu)，但本報(bào)告中詳細(xì)介紹的所有結(jié)果均是使用轉(zhuǎn)速為k的FASA驅(qū)動(dòng)器在DtaAP..1和.1系統(tǒng)上測(cè)試得到7測(cè)成功的主要衡量標(biāo)用戶體2,500個(gè)用戶已經(jīng)完成登錄LiquidwareLabsUX衡量的用戶DataONTAP8.0.1：100的用戶獲DataONTAP8.1：100的用戶獲得測(cè)成功的主要衡量標(biāo)用戶體2,500個(gè)用戶登錄之前訪問(wèn)過(guò)，之后又重新啟動(dòng)的VM。DLL都必須從磁盤(pán)加載。LiquidwareLabsUX衡量的用戶DataONTAP8.0.1：100的用戶獲DataONTAP8.1：100的用戶獲得測(cè)成功的主要衡量標(biāo)啟動(dòng)時(shí)VMwarevCenter控制2,500DLL都不必從磁盤(pán)加載。啟動(dòng)所用的總時(shí)間DataONTAP8.0.1：36分DataONTAP8.1：21分夠帶來(lái)最佳用戶體驗(yàn)夠帶來(lái)最佳用戶體驗(yàn)、最高吞吐量和最低延遲，而且它達(dá)到以上目標(biāo)所需的每次IO操作成本最低。這些圖表從存儲(chǔ)控制器的角度展示吞吐量和IOPS。請(qǐng)觀察從每秒操作數(shù)和吞吐量角度衡量的各工作負(fù)載階段之間的明確界限。請(qǐng)注意，在啟動(dòng)場(chǎng)景中，占主導(dǎo)地位的是相對(duì)大量的讀取操作，這些操作使吞吐量超過(guò)了每秒0MB的峰值。另外，初始登錄場(chǎng)/寫(xiě)入的操作數(shù)較為均衡，讀取操作使峰值吞吐量超過(guò)了每秒0MB。最后，用戶啟動(dòng)自己的VM并且登錄桌面之后，相較于啟動(dòng)場(chǎng)景和登錄場(chǎng)景，穩(wěn)定狀態(tài)工作負(fù)載在PS和吞吐量方面均出現(xiàn)大幅下滑。另請(qǐng)注意，如圖12/寫(xiě)入操作的工作負(fù)載分配比會(huì)變?yōu)?，但是，吞吐量分配會(huì)隨著與初始讀取活動(dòng)相關(guān)的更多工作（例如加載應(yīng)用程序庫(kù)和打開(kāi)/讀取文件）緩存在VM來(lái)賓操作系(OS)中而漸趨平衡圖1)每秒讀取和寫(xiě)入操作圖2)讀取和寫(xiě)入吞吐圖35中的圖表突出顯示了存儲(chǔ)控制器所報(bào)告的操作大小。請(qǐng)注意，工作負(fù)載分配及其數(shù)量會(huì)隨/順序讀取操作百分比，這個(gè)數(shù)字一直保持較為均衡的狀態(tài)。83)啟動(dòng)時(shí)的讀3)啟動(dòng)時(shí)的讀取操作細(xì)圖圖4)初始登錄時(shí)的讀取操作細(xì)分9圖5)穩(wěn)定狀圖5)穩(wěn)定狀態(tài)時(shí)的讀取操作細(xì)基于該目標(biāo)，本報(bào)告的著重點(diǎn)包括詳實(shí)記錄使用的測(cè)試方對(duì)各種配置進(jìn)行比照，展示NetApp技術(shù)的功能最后，驗(yàn)證50,000席位報(bào)告中所詳述的性這些重點(diǎn)的共同目的在于讓讀者能夠重現(xiàn)我們的測(cè)試、選擇適合其環(huán)境的最佳技術(shù)、正確調(diào)整工作負(fù)載的大小并且更好地從總體上了解VD。最后，我們的測(cè)試顯示，在VDI環(huán)境中實(shí)現(xiàn)出色性能需要的不只是支持穩(wěn)定狀態(tài)工作負(fù)載（通常認(rèn)為每個(gè)虛擬桌面達(dá)到2個(gè)PS）的能力這么簡(jiǎn)單。我們發(fā)現(xiàn)，要實(shí)現(xiàn)總體良好的用戶體驗(yàn)，還必須考慮許多其他方面。本報(bào)告接下來(lái)的內(nèi)容提供與測(cè)試場(chǎng)景相關(guān)的詳細(xì)信息，其中不僅包括各種工作負(fù)載的細(xì)節(jié)和各個(gè)測(cè)試結(jié)果，而且還包括用戶體驗(yàn)預(yù)測(cè)。 環(huán)NetApp在由2,500個(gè)虛擬桌面構(gòu)成的“半POD”單元中執(zhí)行測(cè)試，這些虛擬桌面分布于454.1服務(wù)器中，擁有一個(gè)NetAppHA對(duì)控制器。由一個(gè)VMwarevCenterVM管理整POD圖6)PODVMware?ViewVMwareView2個(gè)連接服務(wù)器（2500個(gè)桌面45個(gè)ESX服務(wù)器1使用由兩個(gè)連接代理和10個(gè)池組成VMwareView4.5連接代理池，將虛擬桌 環(huán)NetApp在由2,500個(gè)虛擬桌面構(gòu)成的“半POD”單元中執(zhí)行測(cè)試，這些虛擬桌面分布于454.1服務(wù)器中，擁有一個(gè)NetAppHA對(duì)控制器。由一個(gè)VMwarevCenterVM管理整POD圖6)PODVMware?ViewVMwareView2個(gè)連接服務(wù)器（2500個(gè)桌面45個(gè)ESX服務(wù)器1使用由兩個(gè)連接代理和10個(gè)池組成VMwareView4.5連接代理池，將虛擬桌面注冊(cè)為專(zhuān)用桌面。每個(gè)池均使用默認(rèn)設(shè)置，包括PCoIP連接協(xié)議映像VM，并且應(yīng)用了《面向Windows7VMwareView優(yōu)化指南》中定義的一系列優(yōu)化以及《VMwareView管理員指南》中建議的優(yōu)化。然后，我們使用NetAppRapidCloneUtilityRCU)克隆2,500VM。vCenter負(fù)責(zé)管理VM啟動(dòng)操作；登錄和虛擬桌面工作負(fù)載由VMwareDesktopRAWC所有測(cè)試均使用的是NetAppFAS3270，但是測(cè)試了包括固態(tài)驅(qū)動(dòng)器(SSD)、串行高級(jí)技術(shù)連接(SerialAdvancedTechnologyAttachment,SATA)15KFC驅(qū)動(dòng)器在內(nèi)的多種驅(qū)動(dòng)器。所有測(cè)試均使用DataONTAP8.0.1和8.1執(zhí)行。 測(cè)試、方法和工具該報(bào)告執(zhí)行的測(cè)試代表客戶期望體驗(yàn)的某些最常見(jiàn)工作負(fù)載場(chǎng)測(cè)試中的場(chǎng)景遵循AcmeCorporation中典型的雙周日歷HA/DRS集 HA/DRS集 HA/DRS集2,500VM/vCenterTM（45ESX主機(jī)初始登錄,初始登錄,0個(gè)用戶在半個(gè)小時(shí)之內(nèi)登錄，因?yàn)槭鞘状蔚卿?，所以測(cè)試存儲(chǔ)控制器上的負(fù)載并衡量這種最差登錄情況下的用戶體驗(yàn)。（之所以認(rèn)為這種情況最糟糕，是因?yàn)樵谒袦y(cè)試場(chǎng)景中，該登錄場(chǎng)景生成的負(fù)載最多。）這些登錄伴隨著創(chuàng)建配置文件，將默認(rèn)的1.5MB配置文件復(fù)制到用戶目錄并且創(chuàng)建包含22MB文件的WindowsMail子目錄。登錄之后，每個(gè)虛擬桌面的用戶均開(kāi)始以下工作：配置Outlook、發(fā)送郵件、創(chuàng)建Word和Excel文件以及查看PowerPoint和Acrobat文檔。典型（星期二）,0個(gè)用戶在半個(gè)小時(shí)之內(nèi)登錄。該場(chǎng)景模仿以下登錄場(chǎng)景：用戶登錄之前已登錄過(guò)并且登錄后未進(jìn)行硬重啟的虛擬桌面，因此用戶的應(yīng)用程序庫(kù)和配置文件保存在內(nèi)存中。由于配/輸出/)極少。在此測(cè)試中，用戶像“初始登錄”那樣登錄，但是由于之前已經(jīng)對(duì)Outlook進(jìn)行配置，所以此時(shí)不會(huì)再該測(cè)試的目的同樣是衡量存儲(chǔ)控制器上的負(fù)載以及用戶體驗(yàn)啟動(dòng)此測(cè)試選中vCenter內(nèi)全部2,500個(gè)虛擬桌面、選擇“啟動(dòng)”、監(jiān)控結(jié)果并且計(jì)時(shí)。除測(cè)試用戶體驗(yàn)之外，該測(cè)試還衡量啟動(dòng)時(shí)間。像在其他場(chǎng)景中一樣，還衡量存儲(chǔ)控制器上的負(fù)載配置文件加載（）,00個(gè)用戶在半個(gè)小時(shí)之內(nèi)登錄。該場(chǎng)景模仿以下登錄場(chǎng)景：用戶登錄之前已經(jīng)登錄過(guò)的永久虛擬桌面（與其他用戶一樣），但是由于之后曾經(jīng)對(duì)其硬重啟，因此每臺(tái)機(jī)器的內(nèi)存已清除。內(nèi)存清除之后，由于登錄時(shí)需要從磁盤(pán)加載用戶的配置文件，因而會(huì)生成存儲(chǔ)/。在該測(cè)試中，用戶所做的工作與在“星期二早晨”登錄場(chǎng)景中做的工作相同。但是由于之前沒(méi)有將應(yīng)用程序庫(kù)加載到內(nèi)存中，這樣就必須打開(kāi)每個(gè)應(yīng)用程序，因此該工作會(huì)生成先前場(chǎng)景中未出現(xiàn)的/。與接受測(cè)試的其他登錄場(chǎng)景一樣，該測(cè)試的目的在于衡量存儲(chǔ)控制器上的負(fù)載以及用戶體驗(yàn)穩(wěn)定狀態(tài)穩(wěn)定狀態(tài)是指以下環(huán)境狀態(tài)：所有用戶已經(jīng)完成登錄并且打開(kāi)了開(kāi)展每日工作所必需的應(yīng)用程序。在該場(chǎng)景中，每位用戶執(zhí)行的工作與在“星期一早晨”和“星期二早晨”場(chǎng)景中登錄后所做的工作完全一樣。此處的目標(biāo)與登錄場(chǎng)景中的一樣，即衡量用戶體驗(yàn)和存儲(chǔ)控制器負(fù)載創(chuàng)建在執(zhí)行任何測(cè)試之前必須存在虛擬桌面。因此，NetApp使用自己的RCU克隆桌面。盡管該測(cè)試不是實(shí)際測(cè)試，但是我們?nèi)匀挥涗泟?chuàng)建虛擬桌面（從開(kāi)始到準(zhǔn)備好啟動(dòng)）花費(fèi)的時(shí)間。AcmeVDI用戶一周的工作”的場(chǎng)景中。例如，在該周的第一天，大量用戶可能會(huì)同時(shí)登錄他們的VM，為一周的工作進(jìn)行準(zhǔn)備。該工作可能包括啟動(dòng)各種應(yīng)用程序和執(zhí)行不同級(jí)別的工作。為了清晰起見(jiàn)，本報(bào)告中所述的所有測(cè)試均指的是日歷上的相應(yīng)日期，就像管理員將系統(tǒng)排定為在這些日期執(zhí)行這些事件一樣。每個(gè)測(cè)試均可回溯到表7中介紹的日歷。7AcmeCorporation日歷。盡可能分散地執(zhí)行所有測(cè)試。我們的測(cè)試顯示，即使沒(méi)有任何7AcmeCorporation日歷。盡可能分散地執(zhí)行所有測(cè)試。我們的測(cè)試顯示，即使沒(méi)有任何額外工作負(fù)載發(fā)生，已啟動(dòng)VM也會(huì)成少量磁盤(pán)I/O。我們發(fā)現(xiàn)該工作負(fù)載主要針對(duì)寫(xiě)入并且主要由系統(tǒng)生成，其次是由svchost.exe和services.exe進(jìn)程生成的。出于本報(bào)告的目的，我們將此稱(chēng)為“滴水”效應(yīng)，這是因?yàn)槊總€(gè)VM均會(huì)生成少量但持續(xù)的工作負(fù)載，因此大量VM生成的這種工作負(fù)載足以影響整體性能。將在第5.7節(jié)的所有測(cè)試均使用SSD、SATA15KRPM光纖通道驅(qū)動(dòng)器在DataONTAP8.0.1上執(zhí)行。考慮到每IO操作成本的原因（內(nèi)容提要中提及的原因），在DataONTAP8.1上執(zhí)行的測(cè)試僅采用15KRPM光纖通道驅(qū)動(dòng)器。為簡(jiǎn)便起見(jiàn)，通過(guò)SATA和SSD執(zhí)行的測(cè)試的結(jié)果包括在該報(bào)告的附錄而不是正文中。為了將環(huán)境恢復(fù)到基準(zhǔn)狀態(tài)，在各次測(cè)試之間要關(guān)閉所有虛擬桌面，并且將聚合恢復(fù)到測(cè)試之前Snapshot?副本并且/或者刷新存儲(chǔ)控制器的內(nèi)存以下章節(jié)將提供有關(guān)如何執(zhí)行每個(gè)測(cè)試案例的詳細(xì)信息創(chuàng)建測(cè)試該測(cè)試的唯一目標(biāo)是，記錄使用tApp虛擬存儲(chǔ)控制臺(tái).1以及配置和克隆功能來(lái)創(chuàng)建,0個(gè)虛擬桌面所花費(fèi)的時(shí)間。該測(cè)試向客戶展示如何在相對(duì)較短的時(shí)間內(nèi)，輕松快速地部署或重新部署數(shù)千個(gè)虛Acmeopotionidgtopotion并且希望輕松整合新員工。以快速方式進(jìn)行部署，這樣公司便可以節(jié)省新員工入職的時(shí)間。在第二個(gè)案例中，客戶對(duì)主模板進(jìn)行了修補(bǔ)并且決定重新部署基礎(chǔ)架構(gòu)。啟動(dòng)測(cè)試啟動(dòng)測(cè)試的主要目標(biāo)是確定在發(fā)生諸如中斷、維護(hù)、修補(bǔ)等事件或任何其他需要快速啟動(dòng)的場(chǎng)景后，恢復(fù)環(huán)境所花費(fèi)的時(shí)間。當(dāng)VMe工具已在所有虛擬桌面上簽入，并且存儲(chǔ)控制器上的網(wǎng)絡(luò)文件系統(tǒng)FS)操作數(shù)和PU利用率都已下降到較低的穩(wěn)定狀態(tài)時(shí)，則視為啟動(dòng)測(cè)試已經(jīng)完成。這些測(cè)試的次要目標(biāo)如下//順序的混合情況以及它們各自的操作大小根據(jù)資源利用率和響應(yīng)時(shí)間，評(píng)估存儲(chǔ)控制器在有大量VM同時(shí)啟動(dòng)時(shí)的性能對(duì)比完全啟動(dòng)所有虛擬桌面所花費(fèi)的總時(shí)周周周周周周周2,50082,500次登82,50012345682,500（30分鐘（啟動(dòng)后782,50089控制啟動(dòng)操作時(shí)，vCenter限制控制啟動(dòng)操作時(shí)，vCenter限制每次只能啟動(dòng)128臺(tái)機(jī)器。各個(gè)虛擬桌面完成啟動(dòng)進(jìn)程之后，它們就會(huì)注意：請(qǐng)記住，衡量每秒操作數(shù)和每秒MB時(shí)，均會(huì)使用128這一限制作為因數(shù)。此測(cè)試選中vCenter內(nèi)的所有2,500個(gè)虛擬桌面、選擇啟動(dòng)操作、監(jiān)控結(jié)果并且計(jì)時(shí)。對(duì)啟動(dòng)測(cè)試執(zhí)行情況進(jìn)行衡量需要借助vCenter日志、數(shù)據(jù)包跟蹤以及由存儲(chǔ)控制器收集并封裝perfstat中的統(tǒng)計(jì)數(shù)據(jù)登錄后執(zhí)行工作負(fù)載測(cè)試除了確定先前所述啟動(dòng)場(chǎng)景的特征之外，我們還觀察了大量用戶登錄后立即開(kāi)展日常工作這樣的登錄場(chǎng)/加載各種應(yīng)用程序（包括MicosoftfficeMicosoftttExplo、tlook和Adobed）以及使用這些應(yīng)用程序編寫(xiě)各種文檔。這些測(cè)試的主要目標(biāo)是通過(guò)iqidebsX衡量用戶體驗(yàn)。次要目標(biāo)是了解不同場(chǎng)景的工作負(fù)載概況；獲取工作負(fù)載概況（涉及讀取/寫(xiě)入和隨機(jī)/順序的混合情況，以及它們各自的操作大?。⒏鶕?jù)資源利用率和響應(yīng)時(shí)間，評(píng)估每個(gè)場(chǎng)景中存儲(chǔ)控制器的性能。場(chǎng)景1：初始登錄工作在星期一早晨8點(diǎn)到8:30之間，2,500個(gè)用戶首次登錄。用戶登錄后就開(kāi)始工作。此工作負(fù)載代表在虛擬桌面刷新或初始部署之后進(jìn)行初始登錄時(shí)可能發(fā)生的情形。之所以挑出這個(gè)工作負(fù)載進(jìn)行測(cè)試是因?yàn)樵诿看蔚卿浲瓿芍熬枰獎(jiǎng)?chuàng)建配置文件。要?jiǎng)?chuàng)建配置文件，至少需要以下兩步：將每個(gè)VMC驅(qū)動(dòng)器中的1.5MB默認(rèn)配置文件復(fù)制到用戶的主目在新的用戶配置文件內(nèi)創(chuàng)建WindowsMail目錄，然后大約寫(xiě)入22MBWindowsMail文在所有受試工作負(fù)載中，該工作負(fù)載的獨(dú)特之處不僅因?yàn)樾枰獎(jiǎng)?chuàng)建配置文件，還是因?yàn)槊總€(gè)用戶Outlook配置為應(yīng)用程序工作負(fù)載場(chǎng)景2星期二早在星期二或星期二之后某天的早晨8:0,0個(gè)用戶登錄。用戶登錄后就開(kāi)始工作。在該場(chǎng)景中，用戶之前曾經(jīng)登錄并打開(kāi)過(guò)應(yīng)用程序。由于之前已經(jīng)將配置文件和應(yīng)用程序庫(kù)加載到內(nèi)存中，因此與首次登錄場(chǎng)景或虛擬桌面登錄之后的登錄場(chǎng)景相比，該場(chǎng)景生成的/O要少得多。場(chǎng)景3星期一早完成重新啟動(dòng)事件之后，2,500個(gè)用戶在星期一早晨8點(diǎn)到8:30之間登錄。該登錄場(chǎng)景發(fā)生時(shí)，每個(gè)用戶的配置文件已經(jīng)存在于各自指定VM中的磁盤(pán)上，但是未加載到內(nèi)存中。因此該登錄場(chǎng)景需要存儲(chǔ)由于每個(gè)應(yīng)用程序均需要將各自的庫(kù)加載到內(nèi)存，因此該場(chǎng)景的工作負(fù)載會(huì)進(jìn)一步增加，而且這個(gè)場(chǎng)景包含在這一周剩下的幾天或這一天剩下的幾小時(shí)里看不到的應(yīng)用程序交互/。該測(cè)試的結(jié)果顯示，所用帶寬以及產(chǎn)生的I/O均比首次登錄場(chǎng)景少，但是比“星期二早晨”登錄場(chǎng)景多關(guān)閉所有2,500個(gè)VM并重新啟動(dòng)之后再開(kāi)始該測(cè)試。該測(cè)試顯示用戶在開(kāi)始一天的工作之前不得不登錄已經(jīng)硬重啟過(guò)的環(huán)境時(shí)會(huì)出現(xiàn)的情況。之前在“啟動(dòng)場(chǎng)景”一節(jié)中所述的任何場(chǎng)景出現(xiàn)之后，可能會(huì)發(fā)生該場(chǎng)景。在開(kāi)始該測(cè)試之前，我們不僅確認(rèn)了系統(tǒng)負(fù)載已經(jīng)恢復(fù)到正常，而且檢查了vCenter日志以確認(rèn)所有VM已經(jīng)重新啟動(dòng)，并且查看了vCenter以確保VMware工具已經(jīng)登錄所有VM。換句話說(shuō)，在開(kāi)始該測(cè)試之前，我們仔細(xì)確認(rèn)了啟動(dòng)進(jìn)程已經(jīng)徹底完成。場(chǎng)景4用戶已經(jīng),0場(chǎng)景4用戶已經(jīng),0個(gè)用戶均已完成登錄進(jìn)程，并且已打開(kāi)當(dāng)天所需的所有應(yīng)用程序。該測(cè)試衡量早晨高峰期結(jié)束之/寫(xiě)入文件、發(fā)送電子郵件和搜索b，但是由于之前已經(jīng)將所需的內(nèi)容存儲(chǔ)在內(nèi)存中，因此這個(gè)時(shí)候的存儲(chǔ)工作負(fù)載處于最低點(diǎn)。該測(cè) 工7中屏幕截圖所示生成環(huán)境中的所有工作負(fù)載。根據(jù)VMware的建議使用所選的應(yīng)用序。VMware告知我們?cè)搼?yīng)用程序混合將生成“有經(jīng)驗(yàn)用戶”的工作負(fù)載（即12IOPS/桌面）。以下MicrosoftOffice的版本為2007。MicrosoftExchange的版本為2010。虛擬桌面設(shè)置為在緩存模式下運(yùn)行Outlook所有登錄后執(zhí)行工作負(fù)載的場(chǎng)景均以相同方式執(zhí)行。用戶通過(guò)RAWC，使用PCoIP登錄。平均每3秒5次登錄，在28分鐘內(nèi)完成了所有登錄。為完成以上工作，使用了25RAWC啟動(dòng)器。每個(gè)啟動(dòng)器都被配置為每15秒登錄一個(gè)虛擬桌面。啟動(dòng)器按順序每隔3秒進(jìn)行一次自身登錄。75秒之后，所有啟動(dòng)器都會(huì)每15秒同時(shí)建立新PCoIP會(huì)話。也就是說(shuō)，我們的測(cè)試使用提供給VMware合作伙 管理指南》中定義的默認(rèn)登錄速率。在每個(gè)虛擬桌面上，應(yīng)用程序的運(yùn)行順序是隨機(jī)的。圖7)屏幕，顯示登錄后執(zhí)行工作負(fù)載場(chǎng)景 最終用戶體驗(yàn)我們 最終用戶體驗(yàn)我們使用LiquidwareLabsStratusphereUX報(bào)告所有登錄測(cè)試中的用戶體驗(yàn)此應(yīng)用程序套件為衡量桌面和概念驗(yàn)證(POC)環(huán)境下的用戶體驗(yàn)提供了準(zhǔn)確的系統(tǒng)化方法。該應(yīng)用程VM、用戶和應(yīng)用程序?qū)е翴/O風(fēng)暴登錄延遲、應(yīng)用程序啟動(dòng)時(shí)間、沒(méi)有響應(yīng)的應(yīng)用程序、磁盤(pán)和CPU隊(duì)在具有指定的用戶和應(yīng)用程序關(guān)聯(lián)的多租戶環(huán)境中，端點(diǎn)、桌面和服務(wù)器的流VM、用戶和應(yīng)用程序工作負(fù)載：CPU/內(nèi)存/磁盤(pán)/顯卡/網(wǎng)絡(luò)，包括磁IOPS和存儲(chǔ)要8顯示Stratusphere的功能如何改進(jìn)桌面支持圖8)Stratusphere（圖片由LiquidwareLabs提供）如圖9中屏幕截圖所示，LiquidwareLabsStratusphereUX按照“好”、“一般”和“差”定義用戶體驗(yàn)：花費(fèi)時(shí)間少于15秒的登錄定義為“好”；少于60秒但多于15秒的為“一般”；多于60秒的為“差”。在以下圖表中，用戶體驗(yàn)采用LiquidwareLabs標(biāo)準(zhǔn)。注意：無(wú)論登錄類(lèi)型或配置文件大小怎樣，“好”、“一般”和“差”的定義都嚴(yán)格遵照標(biāo)準(zhǔn)。因此，無(wú)論配置文件的大小或狀態(tài)如何，只要花費(fèi)時(shí)間少于15秒就屬于“好”。圖9)顯示機(jī)器體驗(yàn)圖9)顯示機(jī)器體驗(yàn)指標(biāo)的VDIUX配置文件屏幕。10中屏幕截圖所示，LiquidwareLabsStratusphereUX將少于或等150毫秒閾值的網(wǎng)絡(luò)延遲義為“好”；少于或等于300毫秒但多于150毫秒的為“一般”；多于300毫秒的為“差”圖10顯示I/O體驗(yàn)指標(biāo)的VDIUX配置文件屏幕。我們使用vSpe.1VMevscsiStts實(shí)用程序，利用其跟蹤標(biāo)記來(lái)確定ESX服務(wù)器內(nèi)VM磁盤(pán)/OvscsiStts特別引人關(guān)注，它具有跟蹤選項(xiàng)，可以記錄/O塊大小和命令類(lèi)型。我們利用這些數(shù)據(jù)確定在各種測(cè)試中遇到的操作混合和操作大小。這樣，我們就可以記錄每個(gè)應(yīng)用程序自重新啟動(dòng)后首次使用時(shí)的行為，并將其與每個(gè)應(yīng)用程序在第二次使用時(shí)的行為進(jìn)行比較。我們還使用由NetApp開(kāi)發(fā)的診斷數(shù)據(jù)收集工具Perfstat 詳細(xì)測(cè)試結(jié)果本報(bào)告接下來(lái)的內(nèi)容將重點(diǎn)介紹多項(xiàng)改進(jìn)并確定工作負(fù)載從啟動(dòng)到穩(wěn)定狀態(tài)的特征。為了保持報(bào)告的完/生成工作負(fù)載的工具。接下來(lái)還有一節(jié)會(huì)介紹使用tApp配置和克隆功能來(lái)創(chuàng)建VM，另有一節(jié)介紹各個(gè)Micosoft應(yīng)用程序的特征請(qǐng)參見(jiàn)附錄中的第.2節(jié)“應(yīng)用程”）。本報(bào)告將比較性能結(jié)果，并在適當(dāng)時(shí)添加用戶體驗(yàn)類(lèi)別。本報(bào)告還會(huì)重點(diǎn)介紹在每個(gè)工作負(fù)載中觀察到//順序混合情況。為了便于閱讀，所有NetApp測(cè)試都被疊加在一個(gè)排定本報(bào)告將比較性能結(jié)果，并在適當(dāng)時(shí)添加用戶體驗(yàn)類(lèi)別。本報(bào)告還會(huì)重點(diǎn)介紹在每個(gè)工作負(fù)載中觀察到//順序混合情況。為了便于閱讀，所有NetApp測(cè)試都被疊加在一個(gè)排定了所有事件的雙周日歷上。這樣疊加的目的是讓讀者了解虛構(gòu)的AcmeCorporation中View管理員“生命周期中的一天”。報(bào)告的所有事件均在NetApp測(cè)試中發(fā)生；所有時(shí)間表都是真實(shí)的；只有疊加AcmeCorporation案例是虛構(gòu)的 創(chuàng)建進(jìn)程AcmeCorporation的變更控制委員會(huì)批準(zhǔn)了于29日（星期天）創(chuàng)建另外2,500個(gè)虛擬桌面。在星期天早晨，物理環(huán)境、View連接代理、所需數(shù)量的ESX服務(wù)器和新vCenterVM均已就緒。Windows764位映像之前就已根據(jù)VMware和Microsoft最佳實(shí)踐進(jìn)行了優(yōu)化，并且安裝了所有需要的應(yīng)用程序。AcmeCorporation從眾多技術(shù)中選擇了利用NetApp克隆技術(shù)進(jìn)行部署。星期天早晨，View管理員準(zhǔn)實(shí)際擴(kuò)建環(huán)境時(shí)利用的是虛擬存儲(chǔ)控制臺(tái)(VSC)套件的子組件NetApp配置和克隆功能(PNC)。該環(huán)境的2,500個(gè)虛擬桌面分布于10個(gè)卷（NFS數(shù)據(jù)存儲(chǔ)庫(kù)）上，另有一個(gè)卷用作“暫存”卷。第一步，VSC先將模板實(shí)際復(fù)制到VSC專(zhuān)門(mén)為此創(chuàng)建的暫存卷。然后，VSC對(duì)暫存卷中新創(chuàng)建的flat-vmdk進(jìn)行249次文件級(jí)克隆，最后對(duì)暫存卷本身進(jìn)行10次克隆。將模板復(fù)制到暫存卷的過(guò)程由網(wǎng)絡(luò)數(shù)據(jù)管理協(xié)議(NDMP)以備份和恢復(fù)的形式完成。1NtAppDMP和fltvmdk文件克隆屬于最早的兩個(gè)階段。完成這些階段之后，控制權(quán)會(huì)根據(jù)虛擬桌面啟動(dòng)之前的自定義規(guī)范交回虛擬中心，并執(zhí)行其DMP進(jìn)程花費(fèi)3分鐘共2分鐘來(lái)備份和恢復(fù)0BfltvmdkC:，文件克隆階段花費(fèi)9分鐘而卷克隆階段僅花費(fèi)6秒。周周周周周周周2,50082,500123456凌晨2點(diǎn)網(wǎng)絡(luò)中斷VM82,500（30分鐘（啟動(dòng)后782,50089圖11)克隆虛擬桌面各階段花費(fèi)間細(xì) 初始登錄AcmeCorporation的圖11)克隆虛擬桌面各階段花費(fèi)間細(xì) 初始登錄AcmeCorporation的員工通常在每天上午8點(diǎn)到8:30之間抵達(dá)公司，星期一早晨也不例外。但是于有2,500個(gè)虛擬桌面是新部署的，因此星期一（30日）早晨會(huì)與其他早上略有不同。在這天早晨，View連接代理會(huì)為2,500位用戶都分配新桌面，而且由于AcmeCorporation尚未使用任何配置文件管實(shí)際所有用戶均使用第3.5節(jié)“工具”中所述的方法，在28分鐘內(nèi)登錄初始登錄后，所有用戶便開(kāi)始自己當(dāng)天的工作。VMwareDesktopRAWC控制環(huán)境中的所有工作負(fù)載，它會(huì)打開(kāi)應(yīng)用程序并代替人工鍵盤(pán)控制。RAWC在每個(gè)虛擬桌面上執(zhí)行以下任務(wù)：配置Outlook，將Outlook客戶端設(shè)置為緩存模為每個(gè)用戶打開(kāi)MicrosoftWordExcel，并在其中創(chuàng)建新文檔并保打開(kāi)MicrosoftPowerPointAdobeAcrobatReader，查看其中現(xiàn)有的文檔打開(kāi)MicrosoftInternetExplorer周周周周周周周2,50082,500123456凌晨2點(diǎn)網(wǎng)絡(luò)中斷VM82500（30分鐘（啟動(dòng)后782,50089從Outlook客戶端寫(xiě)三封電子郵件并發(fā)RAWC隨機(jī)確定每個(gè)虛擬桌面上的各個(gè)應(yīng)用程序的運(yùn)行順序用戶表從Outlook客戶端寫(xiě)三封電子郵件并發(fā)RAWC隨機(jī)確定每個(gè)虛擬桌面上的各個(gè)應(yīng)用程序的運(yùn)行順序用戶表8報(bào)告用戶群體在星期一早晨初始登錄場(chǎng)景期間登錄所花費(fèi)的時(shí)間通過(guò)LiquidwareLabsStratusphereUX獲取登錄時(shí)間。如前所述，LiquidwareLabs將登錄時(shí)間少15秒閾值的用戶登錄體驗(yàn)定義為“好”，少于60秒但多于15秒的用戶登錄體驗(yàn)定義為“一般”，60秒的用戶登錄體驗(yàn)定義為“差”表8)初始登錄的用戶體驗(yàn)（以為單）注意：48450GBFC15K驅(qū)動(dòng)器的FAS3270，環(huán)路速率：4Gbps因此，體驗(yàn)為“差”的用戶數(shù)量減少，即使體驗(yàn)仍然為“差”的用戶的情況也有所改善。表9顯示環(huán)境中的用戶的登錄體驗(yàn)。例如，45%的用戶的登錄體驗(yàn)為“好”，他們的平均登錄時(shí)間為5秒。 9)初始登錄用戶體驗(yàn)（“好”、“一般”和“差”登錄時(shí)間的百分比）注意：48450GBFC15K驅(qū)動(dòng)器的FAS3270，環(huán)路速率：4Gbps在下一節(jié)中，請(qǐng)注意存儲(chǔ)控制器的利用率達(dá)到或接近容量上限。同時(shí)，在應(yīng)用程序加載時(shí)間方面LiquidwareLabsStratusphereVDIUX所報(bào)告的用戶體驗(yàn)是可接受的系統(tǒng)如表10中所述，存儲(chǔ)控制器的性能處于較高水平。請(qǐng)注意，從DataONTAP8.0.1升級(jí)到8.1之后吞吐量增加了140%，但是由于CPU利用率略有提升，因此存儲(chǔ)控制器延遲反而縮短了80%。有關(guān)促成這一性能提升的關(guān)鍵技術(shù)進(jìn)步的詳情，請(qǐng)參閱第1節(jié)“內(nèi)容提要”中有關(guān)虛擬存儲(chǔ)分層的討論。配用戶總超過(guò)15秒）用戶百分“一般”登錄時(shí)（15秒且不60秒）用戶百分少于60秒）用戶百分DataONTAP27%（平均6秒35%（平均35秒38%（平均86秒DataONTAP45%（平均5秒52%（平均40秒3%（64秒要DataONTAP8.0.1升級(jí)到DataONTAP8.1之后，初始登錄體驗(yàn)為“差”的用戶數(shù)量大幅較（從38%減少到3%）DataONTAP8.0.1升級(jí)到DataONTAP8.1之后，體驗(yàn)為“差”的用戶的登錄耗時(shí)也縮短了25%（從86秒縮短到64秒）配登錄耗時(shí)用戶體驗(yàn)最長(zhǎng)耗登錄耗時(shí)用戶登錄體驗(yàn)標(biāo)準(zhǔn)偏DataONTAP4612434DataONTAP257720DataONTAP8.0.1升級(jí)到DataONTAP8.1之后，用戶的平均登錄時(shí)間縮短46%（從46秒縮短25秒）要在初始登錄場(chǎng)景中，主要瓶頸是只有一個(gè)萬(wàn)兆以太網(wǎng)網(wǎng)絡(luò)接口卡(NIC)。該網(wǎng)卡發(fā)送的傳輸-暫停幀占接收在初始登錄場(chǎng)景中，主要瓶頸是只有一個(gè)萬(wàn)兆以太網(wǎng)網(wǎng)絡(luò)接口卡(NIC)。該網(wǎng)卡發(fā)送的傳輸-暫停幀占接收到的數(shù)據(jù)包的5%。這樣會(huì)導(dǎo)致客戶端延遲遠(yuǎn)遠(yuǎn)超出存儲(chǔ)控制器報(bào)告的延遲。為了緩解這種阻塞狀況，NetApp建議將工作負(fù)載分流到兩個(gè)單獨(dú)的萬(wàn)兆以太網(wǎng)網(wǎng)卡。10從吞吐量、每秒操作數(shù)和延遲方面，對(duì)DataONTAP8.0.18.1進(jìn)行對(duì)比10初始DataONTAP8.0.18.1的對(duì)比結(jié)果。注意：48450GBFC15K驅(qū)動(dòng)器的FAS3270，環(huán)路速率：4Gbps為簡(jiǎn)潔起見(jiàn)，從現(xiàn)在開(kāi)始，本節(jié)將使用圖形詳細(xì)介紹DataONTAP8.1配置。我們觀察到似的曲線和指標(biāo)，但吞吐量較低，如表10中所述。8.0也具有圖12顯示由2500個(gè)用戶的初始登錄及登錄之后的每日準(zhǔn)備工作的工作負(fù)載生成的讀取和寫(xiě)入吞吐量。用戶登錄后就開(kāi)始工作，因此應(yīng)用程序負(fù)載與登錄和配置文件負(fù)載產(chǎn)生重疊。讀取操作占網(wǎng)絡(luò)傳輸數(shù)據(jù)的71%（平均311MB/秒），寫(xiě)入操作占剩余的29%（平均129MB/秒）。圖12)初始登錄時(shí)的讀取和寫(xiě)入吞13顯示由2500個(gè)用戶的初始登錄及登錄之后的每日準(zhǔn)備工作的工作負(fù)載生成的每秒讀取/寫(xiě)入操作數(shù)。讀取操作占NFS工作負(fù)載的53%，寫(xiě)入操作占43%。查找操作（未顯示）約占剩余的2%。注意：用戶登錄后就開(kāi)始工作，因此應(yīng)用程序負(fù)載與登錄和配置文件負(fù)載產(chǎn)生重疊。Data每秒讀取操作每秒寫(xiě)入操作216秒98秒5.0644.3DataONTAP311秒129秒0.9511.2吞吐量增加140%會(huì)直接影響全部2500個(gè)虛擬桌面完成登錄所需的時(shí)間，這使個(gè)人用戶體驗(yàn)和整體存儲(chǔ)控制器延遲縮短CPU利用率僅略有提升（提升幅度少于用戶延遲完全符合由LiquidwareLabsUX定義為“好”的標(biāo)（“好”不超過(guò)150毫秒，“一般”多于150毫秒且不超過(guò)300毫秒，“差”多于300毫秒）要圖13)初始登錄時(shí)的每秒讀取圖13)初始登錄時(shí)的每秒讀取和寫(xiě)入操作數(shù)。14顯示存儲(chǔ)控制器為NFS協(xié)議報(bào)告的延遲。其中顯示整個(gè)登錄期間的讀?。ㄆ骄耄ㄆ骄?.2毫秒）協(xié)議延遲。0.9毫秒）和圖14)初始登錄中的讀/圖15顯示由ESXTOP批處理模式報(bào)告并由ESXTOP編譯的來(lái)賓操作系統(tǒng)延遲。ESXTOP批處理式使用3秒最小取樣率。X軸是取樣數(shù)。由于該圖代表3秒取樣率，因此X軸的值乘以3即可得要來(lái)賓操作系統(tǒng)遇到的延遲遠(yuǎn)高于存儲(chǔ)控制器報(bào)告的延遲，但是仍然在SttspeX暫停幀占接收到的數(shù)據(jù)包的%。這樣會(huì)導(dǎo)致如圖5所示的客戶端延遲。在接受測(cè)試的每個(gè)DtaAP版本中，該問(wèn)題只會(huì)在初始登錄場(chǎng)景中出現(xiàn)。）為了緩解這種阻塞狀況，NtApp建議將工作負(fù)載分流到兩個(gè)單獨(dú)的萬(wàn)兆以太網(wǎng)網(wǎng)卡。圖15)初始登錄時(shí)的讀圖15)初始登錄時(shí)的讀取和寫(xiě)入如圖16所示，在此期間，平均占用了全部四個(gè)物理保持在較低水平，CPU利用率仍然會(huì)是這樣。CPU容量的95%。請(qǐng)注意，即使存儲(chǔ)控制器延圖16初始CPU利用工作負(fù)載開(kāi)始此測(cè)試時(shí)，NetApp接受了針對(duì)虛擬桌面的行業(yè)標(biāo)準(zhǔn)規(guī)模調(diào)整做法，也就是，根據(jù)期望用戶生成的操作數(shù)將所有用戶分組為多個(gè)操作數(shù)分段。另外，虛擬桌面工作負(fù)載被定義為不包含順序I/O，而且其I/O增量4KB8KB。此外整虛擬桌面I/O大小時(shí)，我們以往認(rèn)為100100%的時(shí)間內(nèi)生成IOPS。但是，數(shù)據(jù)包跟蹤、vscsiStats、存儲(chǔ)控制器統(tǒng)計(jì)和ESXTOP已證實(shí)并非如此。/順序混合和并發(fā)用戶操作。在本報(bào)告中，并發(fā)被定義為同時(shí)生成以存儲(chǔ)為目標(biāo)的/O的虛擬桌面的數(shù)量。在圖17的圖表中列出了讀取操作大小及其各自的特征（順序或隨機(jī)）。統(tǒng)計(jì)數(shù)據(jù)本身取自計(jì)數(shù)器管理工作負(fù)載并不都是同一大小圖17中的圖表就是細(xì)分成了多個(gè)操作數(shù)分段。每個(gè)分段包含介于指定大小與下一報(bào)告操作大小并非所有工作負(fù)載都是隨機(jī)的：在所有讀取操作中，有50%是順序讀取要圖初始登錄時(shí)的讀取操作細(xì)圖初始登錄時(shí)的讀取操作細(xì)表11記錄從虛擬桌面自身角度記錄的工作負(fù)載（也就是ESXTOP中捕獲的工作負(fù)載）。在測(cè)試間，ESXTOP在環(huán)境中的所有服務(wù)器上持續(xù)以批處理模式運(yùn)行，采用最低取樣間隔：3秒我們從ESXTOP輸出中提取到以下信息在特定測(cè)試中以不同時(shí)間間隔同時(shí)執(zhí)行讀取或?qū)懭氩僮鞯奶摂M桌面的數(shù)量。這就讓我們有了在給定每個(gè)活動(dòng)桌面生成的平均讀取和寫(xiě)入操作和吞吐量（以MB/秒為單位）每個(gè)讀取和寫(xiě)入操作的平均大小1ESXP生成的圖表記錄從虛擬桌面的角度記錄的并發(fā)數(shù)、/O速率和操作大小，如ESXP所報(bào)告。該表格的目的是解釋并發(fā)的重要作用，個(gè)別工作中的虛擬機(jī)可能會(huì)非常繁忙，但是從整體上評(píng)估所有虛擬機(jī)得到的結(jié)果就沒(méi)有如此繁忙。平均來(lái)講，在任意指定的一秒，只有20%的虛擬桌面生成讀取操作，70%的虛擬桌面生成寫(xiě)入操作。因此，無(wú)法實(shí)現(xiàn)100%并發(fā)。如果忽略并發(fā)，在初始登錄場(chǎng)景中平均每個(gè)虛擬桌面生成的IOPS為12ESXTOP進(jìn)一步印證了來(lái)自存儲(chǔ)控制器的數(shù)據(jù)，該數(shù)據(jù)表明IOPS高于最初認(rèn)定的VDI常見(jiàn)工作負(fù)載（即4KB或8KB）。ESXTOP報(bào)告的平均IOPS和吞吐量會(huì)密切跟蹤由存儲(chǔ)控制器報(bào)告的值。要表11)初始登錄時(shí)的并發(fā)數(shù)、速率以及讀取和入操作大小在圖18中，由ESXTOP生成的圖表還顯示由來(lái)賓操作系統(tǒng)表11)初始登錄時(shí)的并發(fā)數(shù)、速率以及讀取和入操作大小在圖18中，由ESXTOP生成的圖表還顯示由來(lái)賓操作系統(tǒng)自身在整個(gè)登錄場(chǎng)景中發(fā)布的平均讀取和圖18)初始登錄時(shí)的讀取和寫(xiě)入作大要18中圖表顯示讀取和寫(xiě)入操作在低于4K到大于60KB的大范圍內(nèi)出現(xiàn)波動(dòng)測(cè)量指值VM總IOPS平均平均讀取平均寫(xiě)入平均讀取吞吐量（MB/秒平均寫(xiě)入吞吐量（MB/秒正在進(jìn)行讀取的VM正在進(jìn)行寫(xiě)入的VM平均讀取大小平均寫(xiě)入大小平均讀取延遲（毫秒平均寫(xiě)入延遲（毫秒針對(duì)一針對(duì)所每個(gè)正在進(jìn)行讀取的VM的平均讀取6每個(gè)正在進(jìn)行寫(xiě)入的VM的平均寫(xiě)入64每個(gè)正在進(jìn)行讀取的VM的平均讀取吞吐量（KB/秒每個(gè)正在進(jìn)行寫(xiě)入的VM的平均寫(xiě)入吞吐量（KB/秒 星期二早晨登錄星期一傍晚，AcmeCorporation員工完成各自當(dāng)天的工作之后停止工作，全都退出 星期二早晨登錄星期一傍晚，AcmeCorporation員工完成各自當(dāng)天的工作之后停止工作，全都退出。之后虛擬桌面便主要處于閑置狀態(tài)，并準(zhǔn)備迎接用戶在星期二早晨像往常一樣在上午8點(diǎn)到8:30之間來(lái)上班并登錄。即使用戶在星期一夜間退出，每個(gè)虛擬桌面的內(nèi)存仍會(huì)保留用戶數(shù)據(jù)（庫(kù)、緩存數(shù)據(jù)等）。實(shí)際在前一天初始登錄時(shí)，用戶已經(jīng)被分配給虛擬桌面。用戶在前一天已經(jīng)登錄并打開(kāi)各自的應(yīng)用程序，盡管他們已經(jīng)關(guān)閉應(yīng)用程序并退出，但應(yīng)用程序庫(kù)和每個(gè)用戶的大部分配置文件仍保留在內(nèi)存中。因此，此次登錄和每日準(zhǔn)備工作所生成的工作負(fù)載會(huì)有所減少。在該報(bào)告獲取的所有登錄和工作負(fù)載場(chǎng)景中，用戶登錄速率為每秒大約3次，而首次登錄與最后登錄間隔6分鐘。在星期二早晨登錄之后，所有用戶均開(kāi)始各自當(dāng)天的工作。VMwareDesktopRAWC控制環(huán)境中的所有工作負(fù)載，它會(huì)打開(kāi)應(yīng)用程序并代替人工鍵盤(pán)控制。RAWC在每個(gè)虛擬桌面上執(zhí)行以下任務(wù)：為每個(gè)用戶打開(kāi)MicrosoftWordExcel，并在其中創(chuàng)建新文檔并保打開(kāi)MicrosoftPowerPointAdobeAcrobatReader，查看其中現(xiàn)有的文檔打開(kāi)MicrosoftInternetExplorer從Outlook客戶端寫(xiě)三封電子郵件并發(fā)RAWC隨機(jī)確定每個(gè)虛擬桌面上的應(yīng)用程序的運(yùn)行順序用戶表12報(bào)告用戶群體在星期二早晨的典型登錄場(chǎng)景期間登錄所花費(fèi)的時(shí)間表12)星期二早晨登錄的用戶體（以秒為單位）配DataONTAP110無(wú)論使用何種版本的DataONTAP，多數(shù)用戶在星期二早晨登錄時(shí)用時(shí)均為1秒要周周周周周周周2,500123456凌晨2點(diǎn)網(wǎng)絡(luò)中斷VM（30分鐘（啟動(dòng)后789注意：48450GBFC15K驅(qū)動(dòng)器的FAS3270，環(huán)路速率：4Gbps星期二早晨登錄場(chǎng)景帶來(lái)的用戶登錄體驗(yàn)全部為“好”（根據(jù)LiquidwareLabsStratusphereUX衡量標(biāo)準(zhǔn)，這意味著登錄所花費(fèi)注意：48450GBFC15K驅(qū)動(dòng)器的FAS3270，環(huán)路速率：4Gbps星期二早晨登錄場(chǎng)景帶來(lái)的用戶登錄體驗(yàn)全部為“好”（根據(jù)LiquidwareLabsStratusphereUX衡量標(biāo)準(zhǔn)，這意味著登錄所花費(fèi)的時(shí)間少于15秒）。表13)星期二早晨登錄用戶體驗(yàn)（）注意：48450GBFC15K驅(qū)動(dòng)器的FAS3270，環(huán)路速率：4Gbps在應(yīng)用程序加載時(shí)間方面，LiquidwareLabsStratusphereVDIUX所報(bào)告的用戶體驗(yàn)是可接受的系統(tǒng)如表4中所述，存儲(chǔ)控制器的性能處于較高水平。請(qǐng)注意，虛擬桌面和存儲(chǔ)控制器之間傳輸?shù)墓ぷ髁浚ㄒ驗(yàn)樘摂M桌面實(shí)際上利用保留在來(lái)賓操作系統(tǒng)緩存中的大量信息）（例如系統(tǒng)、svchost.exe和服務(wù)）。為獲取進(jìn)一步的詳情，表14從吞吐量、每秒操作數(shù)和延遲方面，對(duì)DataONTAP8.0.18.1進(jìn)行對(duì)比表14星期二早晨登錄期間DataONTAP8.0.1與8.1的對(duì)比結(jié)果為簡(jiǎn)潔起見(jiàn)，從現(xiàn)在開(kāi)始，本節(jié)將使用圖形詳細(xì)介紹DataONTAP8.1配置。我們觀察到DataONTAP8.0也具有類(lèi)似的曲線和指標(biāo)，但吞吐量較低，如表14中所述。圖9中的圖表顯示由0個(gè)用戶的星期二早晨登錄及登錄之后的每日準(zhǔn)備工作的工作負(fù)載生成的讀取和寫(xiě)入吞吐量。用戶登錄后就開(kāi)始工作，因此應(yīng)用程序負(fù)載與登錄和配置文件負(fù)載產(chǎn)生重疊。讀取操作占網(wǎng)絡(luò)傳輸數(shù)據(jù)的%（7MB），寫(xiě)入操作占剩余的%（0MB）。Data26秒18秒0.90.4DataONTAP17秒20秒0.30.2要如表14所示，即使在操作中寫(xiě)入占主導(dǎo)地位，無(wú)需從磁盤(pán)加載應(yīng)用程序DLL或配置文件，對(duì)存儲(chǔ)控制配用戶總超過(guò)15秒）用戶百分“一般”登錄時(shí)（15秒且不60秒）用戶百分少于60秒）用戶百分DataONTAP100%（平均1秒DataONTAP100%（平均1秒配DataONTAP11.50圖19)星期二早晨登錄的讀圖19)星期二早晨登錄的讀取和寫(xiě)入吞吐量。圖20中的圖表顯示由2,500個(gè)用戶的登錄及登錄之后的每日準(zhǔn)備工作的工作負(fù)載生成的每秒讀取寫(xiě)入操作數(shù)。讀取操作占 工作負(fù)載的 15%，寫(xiě)入操作占 77%。查找操作（未顯示）約占剩余的由于用戶登錄后便開(kāi)始工作，因此用戶的工作負(fù)載和后臺(tái)工作會(huì)與登錄事件發(fā)生重疊。6圖20)星期二早晨登錄時(shí)的每秒取和寫(xiě)入操作數(shù)21顯示存儲(chǔ)控制器為NFS協(xié)議報(bào)告的延遲。其中顯示整個(gè)登錄期間的讀?。ㄆ骄耄ㄆ骄?.2毫秒）協(xié)議延遲。0.3毫秒）和要與前面的案例一樣，在圖表上，首次登錄時(shí)間采用3秒最小取樣率在嘗試進(jìn)行首次登錄之前，每秒大約有2,000次寫(xiě)入操作，而讀取操作寥寥無(wú)幾。我們對(duì)這些操作的來(lái)源進(jìn)行了研究，發(fā)現(xiàn)在各VM上運(yùn)行的系統(tǒng)、svchost.exeservices.exe是這些I/O的來(lái)源。有關(guān)更多信息，請(qǐng)參見(jiàn)第5.7節(jié)的“觀察結(jié)果和經(jīng)驗(yàn)總結(jié)”。即使每秒操作數(shù)增加約100%，登錄后的平均寫(xiě)入大小仍然保持4KB圖21)星期二早晨登錄圖21)星期二早晨登錄的讀取和入?yún)f(xié)議延遲圖22中的圖表顯示由ESXTOP批處理模式報(bào)告并由ESXTOP編譯的來(lái)賓操作系統(tǒng)延遲。ESXTOP批處理模式使用3秒最小取樣率。X軸是取樣數(shù)。由于該圖代表3秒取樣率，因此將即可得到真正的運(yùn)行時(shí)間。請(qǐng)注意，延遲對(duì)應(yīng)存儲(chǔ)控制器上的延遲（這毫不奇怪）。X軸的值乘3圖22)星期二早晨登錄的讀取和入延如圖23中的圖表所示，在此期間，平均占用了全部四個(gè)物CPU容量的23%圖23)星期二早晨登錄圖23)星期二早晨登錄的CPU利用率工作負(fù)載和本報(bào)告中所列的其他工作負(fù)載一樣，在I/O大小、順序和并發(fā)數(shù)方面，星期二早晨登錄場(chǎng)景的工作負(fù)載特征也不同以往?；叵胍幌隆安l(fā)數(shù)”的定義，在這里它還是指同時(shí)生成以存儲(chǔ)為目標(biāo)的I/O的虛擬圖24中列出了讀取操作大小及其各自的特征（順序或隨機(jī)）。統(tǒng)計(jì)數(shù)據(jù)本身取自計(jì)數(shù)器管理程序預(yù)讀圖星期二早晨登錄的讀取操作細(xì)要工作負(fù)載并不都是同一大小圖24中的圖表就是細(xì)分成了多個(gè)操作數(shù)分段。每個(gè)分段包含介于指定大小與下一報(bào)告操作大小并非所有工作負(fù)載都是隨機(jī)的：在所有讀取操作中，有50%是順序讀取15記錄從虛擬桌面自身角度記錄的工作負(fù)載（也就是在ESXTOP中捕獲的工作負(fù)載）。在測(cè)試期間，ESXTOP在環(huán)境中的所有服務(wù)器上持15記錄從虛擬桌面自身角度記錄的工作負(fù)載（也就是在ESXTOP中捕獲的工作負(fù)載）。在測(cè)試期間，ESXTOP在環(huán)境中的所有服務(wù)器上持續(xù)以批處理模式運(yùn)行，采用最低取樣間隔：3秒。在表15中，由ESXTOP生成的圖表記錄從虛擬桌面的角度記錄的并發(fā)數(shù)、I/OESXTOP所報(bào)告。速率和操作大小，表星期二早晨登錄時(shí)并發(fā)數(shù)、速率以及讀取和寫(xiě)入操作大小在圖25中，由ESXTOP生成的圖表還顯示由來(lái)賓操作系統(tǒng)自身在整個(gè)登錄場(chǎng)景中發(fā)布的平均讀取和要25中圖表顯示讀取和寫(xiě)入操作在低于4K到大于100KB的大范圍內(nèi)出現(xiàn)波動(dòng)測(cè)量指值VM總IOPS平均平均讀取平均寫(xiě)入平均讀取吞吐量（MB/秒平均寫(xiě)入吞吐量（MB/秒正在進(jìn)行讀取的VM正在進(jìn)行寫(xiě)入的VM平均讀取大小平均寫(xiě)入大小8平均讀取延遲（毫秒平均寫(xiě)入延遲（毫秒1針對(duì)一針對(duì)所每個(gè)正在進(jìn)行讀取的VM的平均讀取每個(gè)正在進(jìn)行寫(xiě)入的VM的平均寫(xiě)入2每個(gè)正在進(jìn)行讀取的VM的平均讀取吞吐量（KB/秒9每個(gè)正在進(jìn)行寫(xiě)入的VM的平均寫(xiě)入吞吐量（KB/秒要平均來(lái)講，在任意給定的一秒，只有4%的虛擬桌面生成讀取操作，62%的生成寫(xiě)入操作。因此，無(wú)法實(shí)現(xiàn)100%并發(fā)。如果忽略并發(fā)，在星期二早晨登錄場(chǎng)景中平均每個(gè)虛擬桌面生成的IOPS為2ESXTOP進(jìn)一步印證了來(lái)自存儲(chǔ)控制器的數(shù)據(jù)，該數(shù)據(jù)表明IOPS高于4KB8KBESXTOP報(bào)告的平均IOPS和吞吐量會(huì)非常貼近由存儲(chǔ)控制器報(bào)告的數(shù)值圖25)星期二早晨登錄的讀取和入操作大小星期二早晨登錄場(chǎng)景的工作圖25)星期二早晨登錄的讀取和入操作大小星期二早晨登錄場(chǎng)景的工作負(fù)載特征既不4KB也不8KB，而是所有大小的混合 重新啟動(dòng)在星期一清晨，AcmeCorporation在排定的維護(hù)時(shí)間內(nèi)遇到網(wǎng)絡(luò)錯(cuò)誤。這一中斷對(duì)存儲(chǔ)控制器服務(wù)器之間的通信產(chǎn)生了影響。中斷大約在清晨:0時(shí)結(jié)束，距離員工8點(diǎn)之后陸續(xù)上班開(kāi)始一天的工作，虛擬桌面管理員只有一個(gè)多小時(shí)的時(shí)間來(lái)確保所有,0個(gè)虛擬桌面均可用。為了確認(rèn)虛擬桌面全部可用，管理員選擇了完全重啟。首先關(guān)閉所有的虛擬桌面并確認(rèn)已關(guān)閉，然后再次啟動(dòng)。啟動(dòng)所,0個(gè)虛擬桌面，直到所有/O穩(wěn)定處于正常的用戶登錄前狀態(tài)，僅僅用了0多分鐘。所有用戶均不受影響。實(shí)際vtr集中控制：選擇所有,0個(gè)虛擬桌面并由vtrVtr限定每次只能并發(fā)執(zhí)行8個(gè)啟動(dòng)操作，每個(gè)虛擬桌面成功啟動(dòng)之后會(huì)退出服務(wù)中心，等待隊(duì)列中的剩余操作就會(huì)填補(bǔ)空缺。因此，確定啟動(dòng)操作大小時(shí)，每個(gè)桌面生成的總PS，而不是乘以環(huán)境中剩下的所有虛擬桌面。批量啟動(dòng)成功之后，虛擬桌面便會(huì)處于閑置狀態(tài)，等待開(kāi)始一天的工作。周周周周周周周2,500登錄+82,5001234562有VM82,500（30分鐘（啟動(dòng)后782,50089系統(tǒng)如表16中所述，存儲(chǔ)控制器的性能處于較高水平。請(qǐng)注意，在整個(gè)啟動(dòng)過(guò)程中，讀取系統(tǒng)如表16中所述，存儲(chǔ)控制器的性能處于較高水平。請(qǐng)注意，在整個(gè)啟動(dòng)過(guò)程中，讀取操作占主導(dǎo)地位，存儲(chǔ)控制器對(duì)CPU的利用一直處于完全利用狀態(tài)。批量啟動(dòng)場(chǎng)景的目標(biāo)是盡快啟動(dòng)所有虛擬桌面。請(qǐng)注意，吞吐量和并發(fā)（而不是延遲）是批量啟動(dòng)場(chǎng)景中的主導(dǎo)因素。要了解更多詳細(xì)信息，表16可以從吞吐量、每秒操作數(shù)和延遲以及啟動(dòng)時(shí)間等方面，對(duì)Data8.0.18.1進(jìn)行對(duì)比16重新DataONTAP8.0.18.1的對(duì)比結(jié)果為簡(jiǎn)潔起見(jiàn)，從現(xiàn)在開(kāi)始，本節(jié)將使用圖形詳細(xì)介紹DataONTAP8.1配置。我們觀察到8.0也具有類(lèi)似的曲線和指標(biāo)，但吞吐量較低，如表16中所述。26中的圖表顯示啟動(dòng)2,500個(gè)虛擬桌面時(shí)生成的讀取和寫(xiě)入吞吐量。讀取操作占網(wǎng)絡(luò)傳輸數(shù)據(jù)的（569MB），寫(xiě)入操作占剩余的9%（56MB）圖26)啟動(dòng)時(shí)的讀取和寫(xiě)入吞吐圖27中的圖表顯示啟動(dòng)2,500個(gè)虛擬桌面時(shí)生成的每秒讀取和寫(xiě)入操作。讀取操作占NFS工作負(fù)載的80%，寫(xiě)入操作占10%。查找操作（未顯示）約占剩余的10%。由于用戶登錄后便開(kāi)始工作，因此秒55秒4毫3毫36分秒56秒2毫1毫21分8.1新增了虛擬存儲(chǔ)分層等技術(shù)增強(qiáng)功能，因此從DataONTAP8.0.1升級(jí)到8.1之后，啟動(dòng)時(shí)縮短42%（從36分鐘縮短到21分鐘）要圖27)啟動(dòng)時(shí)圖27)啟動(dòng)時(shí)的每秒讀取和寫(xiě)入操圖28中的圖表顯示存儲(chǔ)控制器為NFS協(xié)議報(bào)告的延遲。其中顯示整個(gè)啟動(dòng)期間的讀?。ㄆ骄?毫秒）和寫(xiě)入（平均1毫秒）協(xié)議延遲。這些延遲之所以都很低，是因?yàn)閂M全都是共享磁盤(pán)上、閃存中（從DataONTAP8.1開(kāi)始因受益于虛擬存儲(chǔ)分層功能還包括RAM中）許多相同數(shù)據(jù)塊的克隆副本?？寺M的這些特性可以實(shí)現(xiàn)極其快速的訪問(wèn)。圖28)啟動(dòng)時(shí)的讀取和寫(xiě)入?yún)f(xié)議ESXP不能獲取啟動(dòng)操作，因此沒(méi)有從虛擬桌面角度記錄啟動(dòng)工作負(fù)載的圖表。由于虛擬桌面開(kāi)始啟動(dòng)之后，首先顯示在ESXP中，而且由于批處理模式中的ESXP只打印一次標(biāo)題行，因此我們沒(méi)有有效的方法來(lái)獲取數(shù)據(jù)并輸出有意義的數(shù)據(jù)。29中的圖表所示，在此期間，平均占用了全部四個(gè)物理CPU容量的97%圖29啟動(dòng)期間的CPU圖29啟動(dòng)期間的CPU利用率工作負(fù)載和本報(bào)告中所列的其他工作負(fù)載一樣，在I/O大小、順序和并發(fā)數(shù)方面，啟動(dòng)場(chǎng)景的工作負(fù)載特征也不同以往?！安l(fā)數(shù)”在此指的是同時(shí)執(zhí)行啟動(dòng)操作的虛擬桌面的數(shù)量。請(qǐng)記住，當(dāng)前的vCenter只允許同時(shí)啟動(dòng)128個(gè)虛擬桌面，其余的要排隊(duì)等候。圖30中列出了讀取操作大小及其各自的特征（順序或隨機(jī)）。統(tǒng)計(jì)數(shù)據(jù)本身取自計(jì)數(shù)器管理程序預(yù)讀圖30)啟動(dòng)時(shí)的讀取操作細(xì)分。要工作負(fù)載并不都是同一大小圖30中的圖表就是細(xì)分成了多個(gè)操作數(shù)分段。每個(gè)分段包含介于指定大小與下一報(bào)告操作大小并非所有工作負(fù)載都是隨機(jī)的：在所有讀取操作中，有50%是順序讀取盡管ESXTOP可能不會(huì)用于該特殊工作負(fù)載，但是會(huì)收集以下信息8個(gè)虛擬桌面同時(shí)啟動(dòng)時(shí)每個(gè)桌面每秒的平均讀取和寫(xiě)入操作數(shù)。該數(shù)值不會(huì)考慮虛擬桌面啟動(dòng)后生成的操作，但是基本上滿足我們的目的：128個(gè)虛擬桌面中盡管ESXTOP可能不會(huì)用于該特殊工作負(fù)載，但是會(huì)收集以下信息8個(gè)虛擬桌面同時(shí)啟動(dòng)時(shí)每個(gè)桌面每秒的平均讀取和寫(xiě)入操作數(shù)。該數(shù)值不會(huì)考慮虛擬桌面啟動(dòng)后生成的操作，但是基本上滿足我們的目的：128個(gè)虛擬桌面中每個(gè)桌面每秒的總操作數(shù)：323次操作/（讀取操作：281次操作/秒，寫(xiě)入操作：42次操作/秒如果忽略由vCenter規(guī)定的128個(gè)虛擬桌面同時(shí)啟動(dòng)的限制，將上面的每秒操作數(shù)除以全部個(gè)虛擬桌面，每個(gè)桌面每秒的操作數(shù)將計(jì)算如下128個(gè)虛擬桌面中每個(gè)桌面每秒的總操作數(shù)：16次操作/（讀取操作：14次操作/秒，寫(xiě)入操作：2次操作/秒但是這樣做并不安全。隨著環(huán)境中虛擬桌面數(shù)量的減少，該方法計(jì)算的每秒操作數(shù)會(huì)增加；而實(shí)際上當(dāng)虛擬桌面數(shù)量增加時(shí)，每秒操作數(shù)應(yīng)該是減少的。星期一早晨登錄對(duì),0個(gè)虛擬桌面進(jìn)行硬重啟會(huì)清除每臺(tái)機(jī)器內(nèi)存中的內(nèi)容。正因?yàn)槿绱?，每個(gè)用戶的配置文件均需/實(shí)際在該報(bào)告獲取的所有登錄和工作負(fù)載場(chǎng)景中，用戶登錄速率確定為每秒大約3次，而首次登錄與最后錄間26分鐘在星期一早晨登錄之后，所有用戶均開(kāi)始各自當(dāng)天的工作。VMwareDesktopRAWC控制環(huán)境中的所有工作負(fù)載，它會(huì)打開(kāi)應(yīng)用程序并代替人工鍵盤(pán)控制。RAWC在每個(gè)虛擬桌面上執(zhí)行以下任務(wù)：為每個(gè)用戶打開(kāi)MicrosoftWordExcel，并在其中創(chuàng)建新文檔并保打開(kāi)MicrosoftPowerPointAdobeAcrobatReader，查看其中現(xiàn)有的文檔打開(kāi)MicrosoftInternetExplorer從Outlook客戶端寫(xiě)三封電子郵件并發(fā)RAWC隨機(jī)確定每個(gè)虛擬桌面上的各個(gè)應(yīng)用程序的運(yùn)行順序用戶表17報(bào)告用戶群體在星期一早晨的啟動(dòng)后登錄場(chǎng)景期間登錄所花費(fèi)的時(shí)間周周周周周周周2,50082,500123456凌晨2點(diǎn)網(wǎng)絡(luò)中斷VM82,500（30分鐘（啟動(dòng)后782,50089表17)星期一早晨登錄的用戶體（以秒為單位）注意：48450GBFC15K驅(qū)動(dòng)器的FAS3270，環(huán)路速率：4GbpsLiquidwareLabsStratusphereUX衡量標(biāo)準(zhǔn)，100%用戶獲得“好”登錄體驗(yàn)（花費(fèi)時(shí)表17)星期一早晨登錄的用戶體（以秒為單位）注意：48450GBFC15K驅(qū)動(dòng)器的FAS3270，環(huán)路速率：4GbpsLiquidwareLabsStratusphereUX衡量標(biāo)準(zhǔn)，100%用戶獲得“好”登錄體驗(yàn)（花費(fèi)時(shí)間少于秒）。表18顯示星期一早晨登錄的用戶體驗(yàn)表18)星期一早晨登錄的用戶體驗(yàn)（）注意：48450GBFC15K驅(qū)動(dòng)器的FAS3270，環(huán)路速率：4Gbps系統(tǒng)如表19中所述，存儲(chǔ)控制器的性能處于較高水平。請(qǐng)注意，無(wú)論從每秒MB角度還是從IOPS角度說(shuō)，虛擬桌面和存儲(chǔ)控制器之間傳輸?shù)墓ぷ髁慷际亲x取操作占大部分?？傮w來(lái)講，讀取操作占數(shù)據(jù)傳輸量的80%，60%的IOPS傳輸給存儲(chǔ)控制器。要了解更多詳細(xì)信息，表19可以從吞吐量、每秒操作數(shù)和延遲方面，對(duì)DataONTAP8.0.18.1進(jìn)表19星期一早晨登錄期間DataONTAP8.0.1與8.1的對(duì)比結(jié)果為簡(jiǎn)潔起見(jiàn)，從現(xiàn)在開(kāi)始，本節(jié)將使用圖形詳細(xì)介紹DataONTAP8.1配置。我們觀察到8.0也具有類(lèi)似的曲線和指標(biāo)，但吞吐量較低，如表19中所述。130秒40秒1.20.9DataONTAP180秒49秒0.40.5要無(wú)論是讀取請(qǐng)求還是寫(xiě)入請(qǐng)求，存儲(chǔ)控制器在協(xié)議級(jí)別的平均響應(yīng)速度均小于1毫秒配用戶總超過(guò)15秒）用戶百分“一般”登錄時(shí)（15秒且不60秒）用戶百分“差”登錄時(shí)（不少60秒）DataONTAP100%（平均1秒DataONTAP100%（平均1秒配DataONTAP150.3DataONTAP120.3要無(wú)論使用何種版本的DataONTAP，多數(shù)用戶在星期一早晨登錄時(shí)用時(shí)均為1秒圖1中的圖表顯示由0圖1中的圖表顯示由0個(gè)用戶的星期一早晨登錄及登錄之后的每日準(zhǔn)備工作的工作負(fù)載生成的讀取和寫(xiě)入吞吐量。用戶登錄后就開(kāi)始工作，因此應(yīng)用程序負(fù)載與登錄和配置文件負(fù)載產(chǎn)生重疊。讀取操作占網(wǎng)絡(luò)傳輸數(shù)據(jù)的%（0MB）%（9MB）。圖31)星期一早晨登錄的讀取和寫(xiě)入吞吐量。圖32中的圖表顯示啟動(dòng)2,500個(gè)虛擬桌面時(shí)生成的每秒讀取和寫(xiě)入操作。讀取操作占NFS工作負(fù)載的62%，寫(xiě)入操作占37%。查找操作（未顯示）剩余的1%左右。用戶登錄后便開(kāi)始工作；因此用戶圖32)星期一早晨登錄的每秒讀取寫(xiě)入操作數(shù)圖33中的圖表顯示存儲(chǔ)控制器為NFS協(xié)議報(bào)告的延遲。其中顯示整個(gè)啟動(dòng)期間的讀?。ㄆ骄蛯?xiě)入（平均0.5毫秒）協(xié)議延遲。0.5毫秒圖33)星期一早晨登錄圖33)星期一早晨登錄的讀取和寫(xiě)延遲（以秒為單）圖34中的圖表顯示由ESXTOP批處理模式報(bào)告并由ESXTOP編譯的來(lái)賓操作系統(tǒng)延遲。ESXTOP批處理模式使用3秒最小取樣率。X軸是取樣數(shù)。由于該圖代表3秒取樣率，因此將X軸的值乘以3即可得到真正的運(yùn)行時(shí)間。請(qǐng)注意，盡管有一些異常值，但是這些異常值并未超出LiquidwareLabsStratusphere所定義的“好”延遲限值范圍，而且絕對(duì)不會(huì)在取樣時(shí)間間隔內(nèi)長(zhǎng)時(shí)間出現(xiàn)。此圖表中的平均延遲如下讀取操作：1.7毫寫(xiě)入操作：1.9毫圖34)星期一晨登錄的來(lái)賓操作系讀取和寫(xiě)入延遲如圖35的圖表中所示，在此期間，平均占用了全部四個(gè)物CPU容量的61%圖35)星期一早晨登錄的CPU圖35)星期一早晨登錄的CPU利用率工作負(fù)載星期一早晨登錄場(chǎng)景還顯示廣泛分布的操作大小，并且I/O中包含的隨機(jī)/順序操作數(shù)較為均衡?；叵胍幌隆安l(fā)數(shù)”的定義，在這里它還是指同時(shí)生成以存儲(chǔ)為目標(biāo)的I/O的虛擬桌面數(shù)。圖36中列出了讀取操作大小及其各自的特征（順序或隨機(jī)）。統(tǒng)計(jì)數(shù)據(jù)本身取自計(jì)數(shù)器管理程序預(yù)讀圖星期一早晨登錄的讀取操作細(xì)表20記錄從虛擬桌面自身角度記錄的工作負(fù)載（也就是ESXTOP中捕獲的工作負(fù)載）。在測(cè)試間，ESXTOP在環(huán)境中的所有服務(wù)器上持續(xù)以批處理模式運(yùn)行，采用最低取樣間隔：3要工作負(fù)載并不都是同一大小圖36中的圖表就是細(xì)分成了多個(gè)操作數(shù)分段。每個(gè)分段包含介于指定大小與下一報(bào)告操作大小隨機(jī)和順序操作的工作負(fù)載較為均衡：在所有讀取操作中，有56%屬于順序操作在表20中，由ESXTOP生成的圖表記錄從虛擬桌面的角度記錄的并發(fā)數(shù)、I/OESXTOP所報(bào)告。速率和操作大小，表星期一早晨登錄時(shí)并發(fā)數(shù)、速在表20中，由ESXTOP生成的圖表記錄從虛擬桌面的角度記錄的并發(fā)數(shù)、I/OESXTOP所報(bào)告。速率和操作大小，表星期一早晨登錄時(shí)并發(fā)數(shù)、速率以及讀取和寫(xiě)入操作大小在圖37中，由ESXTOP生成的圖表還顯示由來(lái)賓操作系統(tǒng)自身在整個(gè)登錄場(chǎng)景中發(fā)布的平均讀取和要讀取和寫(xiě)入操作在低于4K