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