客戶想要 VDI。 我確實研究了 SimpliVity + VDI Citrix 虛擬桌面組合。 適用於所有操作員、城市辦公室員工等。 光是第一波遷移就有五千用戶，因此他們堅持進行負載測試。 VDI 可能會開始放慢速度，也可能會平靜地躺下 - 但由於通道問題，這種情況並不總是會發生。 我們專門為 VDI 購買了一個非常強大的測試包，並加載基礎設施，直到它對磁碟和處理器的負擔過重。
因此，我們需要一個塑膠瓶和 LoginVSI 軟體來進行複雜的 VDI 測試。 我們擁有可供 300 個使用者使用的授權。 然後，我們將 HPE SimpliVity 380 硬體裝入適合每台伺服器最大用戶密度任務的套件中，分割具有良好超額訂閱的虛擬機，在其上安裝 Win10 辦公室軟體並開始測試。
我們走吧！
系統
兩個 HPE SimpliVity 380 Gen10 節點（伺服器）。 在各個：
- 2 個英特爾至強鉑金 8170 26c 2.1Ghz。
- RAM：768GB、12 個 64GB LRDIMM DDR4 2666MHz。
- 主磁碟控制器：HPE Smart Array P816i-a SR Gen10。
- 硬碟機：9 個 1.92 TB SATA 6Gb/s SSD（採用 RAID6 7+2 配置，即，這是 HPE SimpliVity 術語中的中型型號）。
- 網路卡：4 x 1Gb Eth（使用者資料）、2 x 10Gb Eth（SimpliVity 和 vMotion 後端）。
- 每個節點內建特殊的 FPGA 卡，用於重複資料刪除/壓縮。
這些節點透過 10Gb 乙太網路互連直接相互連接，無需外部交換機，該交換機用作 SimpliVity 後端並透過 NFS 傳輸虛擬機資料。 叢集中的虛擬機器資料始終在兩個節點之間進行鏡像。
這些節點組合成一個由 vCenter 管理的 Vmware vSphere 叢集。
為了進行測試，部署了網域控制站和 Citrix 連線代理程式。 網域控制器、代理程式和 vCenter 放置在單獨的叢集上。
作為測試基礎設施，300 個虛擬桌面以專用 - 完整複製配置部署，即每個桌面都是虛擬機器原始映像的完整副本，並保存使用者所做的所有變更。
每個虛擬機器有 2vCPU 和 4GB RAM：
虛擬機器上安裝了測試所需的以下軟體：
- Windows 10（64 位元），版本 1809。
- Adobe Reader XI。
- Citrix 虛擬交付代理程式 1811.1。
- 多羅 PDF 1.82。
- Java 7 更新 13。
- 微軟 Office 專業增強版 2016。
節點之間——同步複製。 集群中的每個資料塊都有兩個副本。 也就是說，現在每個節點上都有一組完整的資料。 對於三個或更多節點的集群，區塊的副本位於兩個不同的位置。 建立新 VM 時，會在其中一個群集節點上建立一個附加副本。 當一個節點發生故障時，先前在該節點上執行的所有虛擬機器都會在具有副本的其他節點上自動重新啟動。 如果某個節點長時間失效，則開始逐步恢復冗餘，叢集恢復到N+1冗餘。
資料平衡和儲存發生在 SimpliVity 本身的軟體儲存層級。
虛擬機器運行虛擬化集群，該集群也將它們放置在軟體儲存上。 辦公桌本身是根據標準模板進行的：金融家和營運官員的辦公桌來進行測試（這是兩個不同的模板）。
測試
為了進行測試，使用了 LoginVSI 4.1 軟體測試套件。 LoginVSI 綜合體由一台控制伺服器和 12 台用於測試連線的機器組成，部署在單獨的實體主機上。
測試以三種模式進行：
基準模式 - 負載案例 300 名知識工作者和 300 名儲存工作者。
標準模式 - 負載狀況 300 電力工作人員。
為了使 Power Worker 能夠運作並增加負載多樣性，LoginVSI 複合體中新增了附加 Power 庫檔案的庫。 為了確保結果的可重複性，所有測試台設定均保留為預設值。
知識和權力工作者測試模擬了在虛擬工作站上工作的使用者的真實工作負載。
儲存工作人員測試是專門為測試資料儲存系統而創建的；它與真實的工作負載相去甚遠，並且主要涉及使用者處理大量不同大小的檔案。
測試期間，使用者登入工作站 48 分鐘，速度約為每 10 秒一名使用者。
Результаты
LoginVSI 測試的主要結果是 VSImax 指標，該指標是根據使用者啟動的各種任務的執行時間編制的。 例如：在記事本中開啟檔案的時間、在 7-Zip 中壓縮檔案的時間等。
官方文件中提供了指標計算的詳細說明 .
換句話說，LoginVSI 重複典型的載入模式，模擬辦公室套件中的使用者操作、閱讀 PDF 等，並測量各種延遲。 有嚴重的延遲程度（「一切都變慢了，無法工作」），在此之前，認為尚未達到最大用戶數。 如果回應時間比這種「一切都很慢」的狀態快1毫秒，則認為系統運作正常，可以增加更多使用者。
以下是主要指標：
指標
所採取的行動
詳細的 описание
載入的元件
N.S.L.D.
文字開放時間
文件重 1 KB
記事本打開並
開啟從池中複製的隨機 1 KB 文檔
ресурсов
CPU 和 I/O
非政府組織
對話開放時間
記事本中的窗口
開啟 VSI-記事本文件 [Ctrl+O]
CPU、RAM 和 I/O
ZHC*
是時候創建高度壓縮的 Zip 檔案了
局部壓縮
隨機 5MB .pst 檔案複製自
資源池
CPU 和 I/O
零碳*
是時候創建弱壓縮的 Zip 檔案了
局部壓縮
隨機 5MB .pst 檔案複製自
資源池
的I / O
中央處理器
算計大
隨機資料數組
建立一個大數組
將在輸入/輸出定時器（I/O定時器）中使用的隨機數據
中央處理器
執行測試時，先計算基本的 VSIbase 指標，該指標顯示系統上無負載時執行作業的速度。 在此基礎上，確定 VSImax 閾值，該閾值等於 VSIbase + 1ms。
關於系統效能的結論是基於兩個指標得出的：VSIbase（確定係統的速度）和 VSImax 閾值（確定係統在不顯著降低效能的情況下可以處理的最大用戶數）。
300 位知識工作者基準
知識工作者是經常以各種小峰值載入記憶體、處理器和 IO 的使用者。 該軟體模擬了要求嚴格的辦公室用戶的工作量，就好像他們不斷地查看某些東西（PDF、Java、辦公室套件、照片檢視、7-Zip）。 當您將使用者從 300 增加到 XNUMX 時，每個使用者的延遲會逐漸增加。
VSImax統計：
VSIbase = 986ms，未達到 VSI 閾值。
SimpliVity 監控的儲存系統負載統計：
對於這種類型的負載，系統可以承受增加的負載，而效能幾乎不會下降。 完成使用者任務的時間平穩成長，測試過程中系統回應時間沒有變化，寫入可達3ms，讀取可達1ms。
結論： 300個知識用戶在目前叢集上工作，沒有任何問題，且互不干擾，達到pCPU/vCPU超額認購1到6。隨著負載的增加，整體延遲均勻增長，但尚未達到規定的限制。
300 名儲存工人基準
這些使用者經常進行寫入和讀取，比例分別為 30 比 70。 這個測試更多是為了實驗而進行的。 VSImax統計：
VSIbase = 1673，240 個使用者達到 VSI 閾值。
SimpliVity 監控的儲存系統負載統計：
這種負載本質上是對儲存系統的壓力測試。 執行時，每個使用者都會將許多不同大小的隨機檔案寫入磁碟。 從本例可以看出，當某些使用者超過一定的負載閾值時，完成寫入檔案任務所需的時間會增加。 同時，主機的儲存系統、處理器和記憶體的負載沒有明顯變化，因此目前無法準確確定延遲的原因。
使用此測試得出的有關係統性能的結論只能透過與其他系統的測試結果進行比較來得出，因為此類負載是合成的且不切實際。 不過，整體來說測試進行得很順利。 一切都很順利，直到 210 個會話，然後奇怪的回應開始了，除了 Login VSI 之外，沒有任何地方追蹤這些回應。
300名電力工人
這些是熱愛CPU、記憶體和高IO的用戶。 這些「高級用戶」經常運行長時間突發的複雜任務，例如安裝新軟體和壓縮機大型檔案。 VSImax統計：
VSIbase = 970，未達到 VSI 閾值。
SimpliVity 監控的儲存系統負載統計：
在測試過程中，其中一個系統節點達到了處理器負載閾值，但這並沒有對其運行產生重大影響：
在這種情況下，系統可以承受增加的負載而不會顯著降低效能。 完成使用者任務的時間平穩成長，測試過程中系統回應時間沒有變化，寫入可達3ms，讀取可達1ms。
定期測試對客戶來說還不夠，我們更進一步：我們增加了虛擬機器特性（用於評估超額訂閱和磁碟大小增加的 vCPU 數量）並添加了額外負載。
在進行附加測試時，使用了以下支架配置：
在 300vCPU、4GB RAM、4GB HDD 配置中部署了 80 個虛擬桌面。
其中一台測試機的配置：
電腦部署在「專用 - 完整複製」選項中：
300 位知識工作者超額認購基準 12
VSImax統計：
VSIbase = 921 ms，未達到 VSI 閾值。
SimpliVity 監控的儲存系統負載統計：
所得的結果與測試之前的 VM 配置類似。
300 位 Power 員工，超額認購 12 人
VSImax統計：
VSIbase = 933，未達到 VSI 閾值。
SimpliVity 監控的儲存系統負載統計：
在此測試期間，也達到了處理器負載閾值，但這並沒有對效能產生重大影響：
所得的結果與測試之前的配置類似。
如果負載運轉 10 小時會發生什麼事？
現在我們看看是否會有“累積效應”，連續運行10個小時的測試。
截面的長期測試和描述應該是為了檢查桁架在長期荷載作用下是否會出現問題。
300 位知識工作者基準 + 10 小時
此外，還測試了 300 名知識工作者的負載情況，然後進行了 10 個小時的使用者工作。
VSImax統計：
VSIbase = 919 ms，未達到 VSI 閾值。
VSImax詳細統計：
該圖顯示在整個測試過程中沒有觀察到效能下降。
SimpliVity 監控的儲存系統負載統計：
在整個測試過程中，儲存系統效能保持不變。
新增合成負載的附加測試
客戶要求為磁碟添加狂野負載。 為此，在每個使用者虛擬機器的儲存系統中新增了一個任務，以便在使用者登入系統時在磁碟上執行合成負載。 負載由 fio 實用程式提供，它允許您透過 IOPS 數量限制磁碟上的負載。 在每台機器中，啟動一個任務以啟動 22 IOPS 70%/30% 隨機讀取/寫入量的額外負載。
300 位知識工作者基準測試 + 每位使用者 22 IOPS
在最初的測試中，我們發現 fio 會為虛擬機器帶來顯著的 CPU 開銷。 這導致主機的CPU迅速過載，大大影響了整個系統的運作。
主機CPU負載：
同時，儲存系統的延遲也自然增加：
運算能力的缺乏在 240 個使用者左右變得至關重要：
根據所得的結果，決定進行 CPU 密集程度較低的測試。
230 名辦公室工作人員基準 + 每位使用者 22 IOPS
為了減少 CPU 的負載，選擇了 Office Workers 負載類型，並且還為每個會話添加了 22 IOPS 的綜合負載。
為了不超過最大 CPU 負載，測試限制為 230 個會話。
此測試由使用者執行10個小時來檢查系統在接近最大負載的情況下長期運行時的穩定性。
VSImax統計：
VSIbase = 918 ms，未達到 VSI 閾值。
VSImax詳細統計：
該圖顯示在整個測試過程中沒有觀察到效能下降。
CPU負載統計：
執行此測試時，主機 CPU 上的負載幾乎達到最大。
SimpliVity 監控的儲存系統負載統計：
在整個測試過程中，儲存系統效能保持不變。
測試期間儲存系統上的負載約為 6 IOPS，比率為 500/60（40 IOPS 讀取，3 IOPS 寫入），即每個工作站約為 900 IOPS。
寫入回應時間平均為 3 毫秒，讀取回應時間最長為 1 毫秒。
總
在模擬 HPE SimpliVity 基礎架構上的實際負載時，所獲得的結果證實了系統能夠支援一對 SimpliVity 節點上至少 300 台完整複製電腦的虛擬桌面。 同時，在整個測試過程中，儲存系統的回應時間都保持在最佳水準。
在實施之前對解決方案進行長時間的測試和比較的方法給我們留下了深刻的印象。 如果您願意，我們也可以測試您的工作負載的效能。 包括其他超融合解決方案。 上述客戶目前正在並行完成另一個解決方案的測試。 它目前的基礎設施只是一組 PC、每個工作場所的一個領域和軟體。 當然，在沒有測試的情況下遷移到 VDI 是相當困難的。 具體來說，如果不將真實使用者遷移到 VDI 場，就很難了解 VDI 場的真實功能。 這些測試可以讓您快速評估特定係統的真實功能，而無需一般使用者的參與。 這就是這項研究的由來。
第二個重要方法是客戶立即承諾適當擴展。 在這裡你可以購買額外的伺服器並添加農場，例如，對於100個用戶，一切都是可以預測的用戶價格。 例如，當他們需要再增加 300 個使用者時，他們會知道在已定義的配置中需要兩台伺服器，而不是重新考慮升級整個基礎架構。
HPE SimpliVity 聯盟的可能性很有趣。 由於業務在地理位置上是分散的，因此在遙遠的辦公室安裝您自己的單獨的 VDI 硬體是有意義的。 在 SimpliVity 聯邦中，每個虛擬機都根據計劃進行複製，能夠在地理上遙遠的叢集之間非常快速地進行複製，並且通道上沒有負載 - 這是一個非常好的水平的內建備份。 在站點之間複製虛擬機器時，會盡可能少使用通道，這使得在存在單一控制中心和一堆分散式儲存站點的情況下建置非常有趣的災難復原架構成為可能。
所有這些結合在一起，可以詳細評估財務方面，並將 VDI 成本疊加到公司的成長計劃上，並了解解決方案的回報速度及其運作方式。 因為任何 VDI 都是一種最終可以節省大量資源的解決方案，但同時，很可能在使用後 5-7 年內沒有經濟高效的機會對其進行更改。
一般來說，如果您有任何不予評論的問題，請透過電子郵件給我寫信 [電子郵件保護].
來源： www.habr.com