В 我們討論了使用 Watcher 的嘗試並提供了測試報告。 我們定期進行此類測試，以平衡大型企業或營運商雲端的其他關鍵功能。
所解決的問題非常複雜，可能需要多篇文章來描述我們的專案。 今天，我們發布該系列的第二篇文章，專門討論平衡雲中的虛擬機器。
一點術語
VmWare公司引入了DRS（分散式資源調度程式）實用程式來平衡他們開發和提供的虛擬化環境的負載。
根據
「VMware DRS（分散式資源調度程序）是一種實用程序，可平衡虛擬環境中的運算負載與可用資源。 該實用程式是名為 VMware Infrastructure 的虛擬化套件的一部分。
借助 VMware DRS，使用者可以定義在虛擬機器 (VM) 之間分配實體資源的規則。 該實用程式可以配置為手動或自動控制。 VMware 資源池可以輕鬆新增、移除或重新組織。 如果需要，可以在不同業務部門之間隔離資源池。 如果一台或多台虛擬機器上的工作負載發生顯著變化，VMware DRS 會在實體伺服器之間重新分配虛擬機器。 如果整體工作負載減少，一些實體伺服器可能會暫時離線並整合工作負載。”
為什麼需要平衡？
在我們看來，DRS 是必備的雲端功能，儘管這並不意味著必須隨時隨地使用 DRS。 根據雲端的目的和需求，對於 DRS 和平衡方法可能有不同的要求。 可能存在根本不需要平衡的情況。 甚至有害。
為了更好地了解何處以及哪些客戶需要 DRS，讓我們考慮他們的目的和目標。 雲可以分為公有雲和私有雲。 以下是這些雲端和客戶目標之間的主要區別。
私有雲/大型企業客戶
公有雲/中小企業、個人
經營者的主要標準和目標
提供可靠的服務或產品
在競爭激烈的市場中降低服務成本
服務要求
各個層級和所有系統元件的可靠性
保證性能
將虛擬機器分為幾個類別
資訊和實體資料安全
SLA 和 XNUMX/XNUMX 支持
最大程度地輕鬆接收服務
服務比較簡單
數據的責任在於客戶
不需要虛擬機器優先級
標準服務等級的資訊安全，客戶責任
可能會有故障
沒有 SLA，品質得不到保證
電子郵件支援
不需要備份
客戶端功能
應用範圍非常廣泛。
公司繼承的遺留應用程式。
為每個客戶提供複雜的客製化架構。
親和力規則。
該軟體在 7x24 模式下不間斷地運作。
即時備份工具。
可預測的循環客戶負載。
典型應用 – 網路平衡、Apache、WEB、VPN、SQL
應用程式可能會停止一段時間
允許在雲端任意分佈虛擬機
用戶端備份
大量客戶端的可預測統計平均負載。
對建築的影響
地理聚類
集中式或分散式儲存
保留腸躁症
計算節點本地資料存儲
平衡目標
負載分佈均勻
最大的應用程式響應能力
最小平衡延遲時間
僅在明顯必要時進行平衡
取出一些設備進行預防性維護
降低服務成本和營運商成本
在低負載的情況下停用某些資源
節能
降低人員成本
我們自己得出以下結論：
對於私有雲提供給大型企業客戶的 DRS 可在以下限制條件下使用：
- 資訊安全並在平衡時考慮親和力規則；
- 發生事故時有足夠的資源儲備；
- 虛擬機器資料位於集中式或分散式儲存系統上；
- 管理、備份和平衡程序的時間分離；
- 僅在客戶端主機聚合內進行平衡；
- 只有在存在強烈不平衡的情況下進行平衡，才是最有效、最安全的VM遷移（畢竟遷移可能會失敗）；
- 平衡相對「安靜」的虛擬機器（遷移「吵雜」的虛擬機器可能需要很長時間）；
- 平衡考慮「成本」－儲存系統和網路的負載（為大客戶客製架構）；
- 考慮每個虛擬機器的個體行為特徵進行平衡；
- 平衡最好在非工作時間（晚上、週末、假日）進行。
對於公有雲為小型客戶提供服務時，DRS 的使用頻率更高，具有進階功能：
- 缺乏資訊安全限制和相似性規則；
- 雲內平衡；
- 在任何合理時間進行平衡；
- 平衡任何虛擬機器；
- 平衡「吵鬧」的虛擬機器（以免打擾其他人）；
- 虛擬機器資料通常位於本機磁碟上；
- 考慮儲存系統和網路的平均效能（雲端架構統一）；
- 根據一般規則和可用的資料中心行為統計資料進行平衡。
問題的複雜性
平衡的困難在於DRS必須與大量的不確定因素一起工作：
- 每個客戶資訊系統的使用者行為；
- 資訊系統伺服器操作的演算法；
- DBMS 伺服器的行為；
- 運算資源、儲存系統、網路的負載；
- 伺服器之間的互動以爭奪雲端資源。
雲端資源上的大量虛擬應用程式伺服器和資料庫的負載隨著時間的推移而發生，其後果可能會在不可預測的時間內顯現出來並相互重疊，產生不可預測的影響。 即使要控制相對簡單的過程（例如，控制引擎、家中的熱水系統），自動控制系統也需要使用複雜的 帶有反饋的演算法。
我們的任務要複雜許多數量級，並且存在系統無法在合理時間內將負載平衡到既定值的風險，即使沒有來自使用者的外部影響。
我們的發展歷史
為了解決這個問題，我們決定不是從頭開始，而是在現有經驗的基礎上，開始與有這方面經驗的專家互動。 幸運的是，我們對問題的理解完全一致。
階段1
我們使用了基於神經網路技術的系統，並嘗試基於它來優化我們的資源。
這個階段的興趣在於測試新技術，其重要性在於應用非標準方法來解決問題，在其他條件相同的情況下，標準方法實際上已經耗盡了自己的力量。
我們啟動了系統，我們真正開始平衡。 我們的雲端規模不允許我們獲得開發人員所說的樂觀結果，但很明顯，平衡正在發揮作用。
同時，我們也有相當嚴重的限制：
- 為了訓練神經網絡，虛擬機器需要在沒有重大變化的情況下運行數週或數月。
- 該演算法旨在根據早期「歷史」數據的分析進行最佳化。
- 訓練神經網路需要相當大量的資料和運算資源。
- 優化和平衡可以相對較少地進行——每隔幾個小時一次，這顯然是不夠的。
階段2
由於我們對現狀不滿意，我們決定修改系統，為此，請回答 主要問題 – 我們為誰而做？
首先 - 針對企業客戶。 這意味著我們需要一個快速運作的系統，而這些公司限制只會簡化實施。
第二個問題 ——「及時」這個詞是什麼意思？ 經過短暫辯論，我們決定可以從 5-10 分鐘的反應時間開始，這樣短期的波動就不會導致系統共振。
第三個問題 – 選擇多少數量的平衡伺服器？
這個問題自行解決了。 通常，客戶端不會將伺服器聚合設定得非常大，這與本文將聚合限制為 30-40 台伺服器的建議一致。
此外，透過對伺服器池進行分段，我們簡化了平衡演算法的任務。
第四個問題 – 學習過程漫長且平衡性極少的神經網路有多適合我們？ 我們決定放棄它，轉而採用更簡單的運算演算法，以便在幾秒鐘內獲得結果。
可以找到使用此類演算法的系統及其缺點的描述
我們實施並啟動了這個系統，並收到了令人鼓舞的結果 - 現在它會定期分析雲端負載並提出移動虛擬機的建議，這些建議基本上是正確的。 即使現在，我們也可以清楚地看到，我們可以為新虛擬機器釋放 10-15% 的資源，同時提高現有虛擬機器的工作品質。
當偵測到 RAM 或 CPU 不平衡時，系統會向 Tionix 調度程序發出命令以執行所需虛擬機器的即時遷移。 從監控系統可以看到，虛擬機器從一台（上層）主機移動到了另一台（下層）主機，並釋放了上層主機（黃色圓圈）的內存，分別佔用了下層主機（白色圓圈）的內存。界）。
現在我們正在嘗試更準確地評估當前演算法的有效性，並試圖找出其中可能存在的錯誤。
階段3
看來可以先冷靜一下，等效果出來了再結束這個話題。
但以下明顯的優化機會推動我們進行了一個新的階段
- 統計數據，例如， и 顯示兩處理器和四處理器系統的效能明顯低於單處理器系統。 這意味著與單處理器系統相比，所有使用者在多處理器系統中購買的 CPU、RAM、SSD、LAN、FC 獲得的輸出顯著減少。
- 資源調度器本身可能有嚴重錯誤， 關於這個話題。
- Intel 和 AMD 提供的用於監控 RAM 和快取的技術使得研究虛擬機器的行為成為可能，並將它們放置在「吵鬧」的鄰居不會幹擾「安靜」的虛擬機器的位置。
- 參數集的擴展（網路、儲存系統、虛擬機器的優先權、遷移成本、遷移準備）。
在總
我們改進平衡演算法的工作結果得出了明確的結論：使用現代演算法可以實現資料中心資源的顯著最佳化（25-30%），同時提高客戶服務品質。
基於神經網路的演算法當然是一種有趣的解決方案，但需要進一步開發，並且由於現有的限制，它不適合在私有雲典型的磁碟區上解決此類問題。 同時，該演算法在規模相當大的公有雲中也表現出了良好的效果。
我們將在接下來的文章中向您詳細介紹處理器、排程器和進階平衡的功能。
來源： www.habr.com