在大型雲端系統中，自動平衡運算資源負載的問題尤其嚴重。 Tionix（雲端服務開發商和營運商，Rostelecom 公司集團的一部分）也解決了這個問題。
而且，由於我們的主要開發平台是Openstack，而我們和所有人一樣都很懶，所以決定選擇一些已經包含在平台中的現成模組。 我們選擇了 Watcher，我們決定用它來滿足我們的需求。
首先，讓我們來看看術語和定義。
術語和定義
目標 是必須實現的人類可讀、可觀察和可測量的最終結果。 有一個或多個策略來實現每個目標。 策略是能夠為給定目標找到解決方案的演算法的實現。
行動 是一個基本任務，改變OpenStack叢集的目標託管資源的目前狀態，例如：遷移虛擬機器（migration）、改變節點的電源狀態（change_node_power_state）、改變nova服務的狀態（change_nova_service_state） ）、變更風格（調整大小） 、註冊NOP 訊息（nop）、在一定時間長度內缺乏操作- 暫停（睡眠）、磁碟傳輸（volume_migrate）。
行動計劃 - 為了實現特定目標而依一定順序執行的特定行動流程。 該行動計劃還包含透過一組績效指標衡量的全球績效。 Watcher 在成功審核後產生行動計劃，其結果是所使用的策略找到了實現目標的解決方案。 行動計劃由一系列連續行動組成。
審計 是優化叢集的請求。 執行最佳化是為了在給定叢集中實現一個目標。 對於每次成功的審核，Watcher 都會產生行動計畫。
審核範圍 是執行稽核的一組資源（可用區、節點聚合器、單一運算節點或儲存節點等）。 每個範本中都定義了審核範圍。 如果不指定審計範圍，則審計整個叢集。
審核模板 — 用於啟動審核的一組已儲存的設定。 需要模板來使用相同的設定多次運行審核。 範本必須包含審核的目的；如果未指定策略，則選擇最合適的現有策略。
簇 是提供運算、儲存和網路資源並由同一個 OpenStack 管理節點管理的實體機的集合。
集群資料模型 (CDM) 是叢集管理的資源的目前狀態和拓撲的邏輯表示。
效率指標 - 指示如何執行使用此策略建立的解決方案的指示器。 績效指標特定於特定目標，通常用於計算最終行動計劃的整體有效性。
功效規格 是與每個目標相關的一組特定功能，定義了實現相應目標的策略在其解決方案中必須實現的各種績效指標。 事實上，在計算其全局有效性之前，該策略提出的每個解決方案都將根據規範進行檢查。
評分引擎 是一個可執行文件，具有明確定義的輸入、明確定義的輸出，並執行純數學任務。 這樣，計算就獨立於執行它的環境——它在任何地方都會給出相同的結果。
觀察者規劃師 - 觀察者決策引擎的一部分。 該模組採用策略產生的一組操作，並建立工作流程計劃，該計劃指定如何及時安排這些不同的操作以及每個操作的先決條件是什麼。
觀察者目標與策略
目標
战略。
虛擬目標
虛擬策略
使用範例評分引擎的虛擬策略
具有調整大小的虛擬策略
節能
節能策略
服務器整合
基本的離線伺服器整合
虛擬機器工作負載整合策略
工作負載平衡
工作負載平衡遷移策略
儲存容量平衡策略
工作負載穩定
吵鬧的鄰居
吵鬧的鄰居
熱優化
基於出口溫度的策略
氣流優化
統一氣流遷移策略
硬件維護
區域遷移
未分類
執行器
虛擬目標 — 用於測試目的的保留目標。
相關策略：虛擬策略、使用範例評分引擎的虛擬策略和具有調整大小的虛擬策略。 Dummy策略是透過Tempest進行整合測試時所使用的虛擬策略。 此策略不提供任何有用的最佳化，其唯一目的是使用 Tempest 測試。
使用範例評分引擎的虛擬策略 - 該策略與前一個策略類似，唯一的區別是使用範例“評分引擎”，該引擎透過機器學習方法進行計算。
帶有調整大小的虛擬策略 - 該策略與前一種策略類似，唯一的區別是使用更改風味（遷移和調整大小）。
未在生產中使用。
節能 — 最大限度地減少能源消耗。 此目標的節能策略與虛擬機器工作負載整合策略（伺服器整合）一起，能夠提供動態電源管理(DPM) 功能，即使在資源利用率低的時期，也可以透過動態整合工作負載來節省能源：虛擬機器移至更少的節點，並且停用不必要的節點。 整合後，此策略根據指定的參數提供開啟/關閉節點的決策：「min_free_hosts_num」 - 等待載入的空閒啟用節點的數量，「free_used_percent」 - 空閒啟用主機佔總負載的百分比機器所佔用的節點數。 為了使該策略發揮作用，必須 啟用並配置 Ironic 以處理節點上的電源循環。
策略參數
範圍
類型
默認情況下
описание
免費使用百分比
聯繫電話
10.0
空閒計算節點數與擁有虛擬機器的計算節點數之比
最小空閒主機數
詮釋
1
最小空閒計算節點數
雲必須至少有兩個節點。 使用的方法是更改節點的電源狀態（change_node_power_state）。 該策略不需要收集指標。
伺服器整合 - 最大限度地減少計算節點的數量（整合）。 它有兩種策略：基本離線伺服器整合策略和虛擬機器工作負載整合策略。
基本離線伺服器整合策略最大限度地減少了使用的伺服器總數，並最大限度地減少了遷移次數。
基本策略需要以下指標：
指標
服務
插件
評論
計算.節點.cpu.百分比
沒有
cpu_util
沒有
策略參數：migration_attempts - 搜尋潛在關閉候選者的組合數量（預設值，0，無限制），period - 從指標資料來源取得靜態聚合的時間間隔（以秒為單位）（預設值，700）。
使用的方法：遷移、改變nova服務狀態（change_nova_service_state）。
VM 工作負載整合策略基於首次擬合啟發式演算法，重點在於測量的 CPU 負載，並嘗試在給定資源容量限制的情況下盡量減少負載過多或過少的節點。 該策略提供了一種解決方案，透過以下四個步驟更有效地利用集群資源：
- 卸載階段－處理過度使用的資源；
- 整合階段－處理未充分利用的資源；
- 解決方案的最佳化－減少遷移次數；
- 禁用未使用的計算節點。
該策略需要以下指標：
指標
服務
插件
評論
記憶
沒有
磁碟根目錄大小
沒有
以下指標是可選的，但如果可用，將提高策略的準確性：
指標
服務
插件
評論
記憶體駐留
沒有
cpu_util
沒有
策略參數： period — 從指標資料來源取得靜態聚合的時間間隔（以秒為單位）（預設為 3600）。
使用與先前策略相同的方法。 更多細節 .
工作負載平衡 — 平衡運算節點之間的工作負載。 目標有三種策略：工作負載平衡遷移策略、工作負載穩定、儲存容量平衡策略。
工作負載平衡遷移策略根據主機虛擬機器工作負載執行虛擬機器遷移。 只要節點的 CPU 或 RAM 利用率百分比超過指定閾值，就會做出遷移決定。 在這種情況下，移動的虛擬機器應該會使節點更接近所有節點的平均工作負載。
需求
- 使用實體處理器；
- 至少兩個物理計算節點；
- 安裝並配置了在每個運算節點上運行的 Ceilometer 元件 - ceilometer-agent-compute 和 Ceilometer API，並收集以下指標：
指標
服務
插件
評論
cpu_util
沒有
記憶體駐留
沒有
策略參數：
範圍
類型
默認情況下
описание
度量
串
'cpu_util'
底層指標是：「cpu_util」、「memory.resident」。
門檻
聯繫電話
25.0
遷移的工作負載閾值。
期
聯繫電話
300
累積時間段雲高儀。
使用的方法是遷移。
工作負載穩定是一種旨在使用即時遷移來穩定工作負載的策略。 此策略基於標準差演算法，判斷叢集是否存在擁塞，並透過觸發機器遷移來回應，以穩定叢集。
需求
- 使用實體處理器；
- 至少兩個物理計算節點；
- 安裝並配置了在每個運算節點上運行的 Ceilometer 元件 - ceilometer-agent-compute 和 Ceilometer API，並收集以下指標：
指標
服務
插件
評論
cpu_util
沒有
記憶體駐留
沒有
儲存容量平衡策略（從 Queens 開始實施的策略） - 此策略根據 Cinder 池上的負載轉移磁碟。 每當池利用率超過指定閾值時，就會做出傳輸決策。 移動的磁碟應該會使池更接近所有 Cinder 池的平均負載。
要求和限制
- 至少兩個 Cinder 池；
- 磁碟遷移的可能性。
- 集群資料模型 - Cinder 集群資料模型收集器。
策略參數：
範圍
類型
默認情況下
описание
音量閾值
聯繫電話
80.0
用於平衡磁碟區的磁碟閾值。
使用的方法是磁碟遷移（volume_migrate）。
吵雜的鄰居 - 識別並遷移「吵雜的鄰居」 - 一種低優先級虛擬機，該虛擬機透過過度使用末級快取對 IPC 方面的高優先級虛擬機的效能產生負面影響。 自己的策略：Noisy Neighbor（使用的策略參數是cache_threshold（預設值為35），當效能下降到指定值時，開始遷移。為了使該策略起作用，啟用 LLC（末級快取）指標， 支援 CMT 的最新英特爾伺服器，以及收集以下指標：
指標
服務
插件
評論
cpu_l3_緩存
沒有
需要英特爾 .
集群資料模型（預設）：Nova 集群資料模型收集器。 使用的方法是遷移。
透過儀表板實現這一目標在皇后區尚未完全實現。
熱優化 — 優化溫度狀況。 出口（排氣）溫度是測量伺服器熱/工作負載狀態的重要熱遙測系統之一。 目標有一種策略，即基於出口溫度的策略，當來源主機的出口溫度達到可配置閾值時，該策略決定將工作負載遷移到熱有利的主機（最低出口溫度）。
為了讓此策略發揮作用，您需要一台安裝並配置了 Intel Power Node Manager 的伺服器 ，以及收集以下指標：
指標
服務
插件
評論
hardware.ipmi.node.outlet_溫度
智能製造管理接口
策略參數：
範圍
類型
默認情況下
описание
門檻
聯繫電話
35.0
遷移的溫度閾值。
期
聯繫電話
30
從監控資料來源取得統計聚合的時間間隔（秒）。
使用的方法是遷移。
氣流優化 ——優化通氣模式。 自己的策略 - 使用即時遷移的統一氣流。 每當伺服器風扇的氣流超過指定閾值時，該策略就會觸發虛擬機器遷移。
為了使該策略發揮作用，您需要：
- 硬體：計算節點<支援NodeManager 3.0；
- 至少兩個計算節點；
- 在每個運算節點上安裝和配置的 ceilometer-agent-compute 和 Ceilometer API 元件，可以成功報告氣流、系統功率、入口溫度等指標：
指標
服務
插件
評論
硬體.ipmi.node.airflow
智能製造管理接口
硬體.ipmi.節點.溫度
智能製造管理接口
hardware.ipmi.node.power
智能製造管理接口
為了讓此策略發揮作用，您需要一台安裝並配置了 Intel Power Node Manager 3.0 或更高版本的伺服器。
限制：該概念不適用於生產。
建議將此演算法與連續審核一起使用，因為每次迭代僅計劃遷移一個虛擬機器。
即時遷移是可能的。
策略參數：
範圍
類型
默認情況下
описание
閾值氣流
聯繫電話
400.0
遷移氣流閾值 單位為0.1CFM
閾值入口_t
聯繫電話
28.0
用於遷移決策的入口溫度閾值
閾值功率
聯繫電話
350.0
用於遷移決策的系統功率閾值
期
聯繫電話
30
從監控資料來源取得統計聚合的時間間隔（秒）。
使用的方法是遷移。
硬件維修 ——硬體維護。 與此目標相關的策略是區域遷移。 此策略是一種在需要硬體維護時有效自動、最小化虛擬機器和磁碟遷移的工具。 策略根據權重製定行動計畫：權重較大的一組行動將先於其他行動計畫。 有兩個配置選項：action_weights 和並行化。
限制：需要配置動作權重和並行化。
策略參數：
範圍
類型
默認情況下
описание
計算節點
排列
與機身相同顏色
用於遷移的計算節點。
儲存池
排列
與機身相同顏色
用於遷移的儲存節點。
並行總數
整數
6
必須並行執行的活動總數。
每個節點並行數
整數
2
每個計算節點並行執行的操作數。
每個池並行
整數
2
每個儲存池並行執行的操作數。
優先
對象
與機身相同顏色
虛擬機器和磁碟的優先權清單。
附附加卷
布爾
假
False — 遷移所有磁碟後將遷移虛擬機器。 正確 — 遷移所有連接的磁碟後，將遷移虛擬機器。
計算節點數組的元素：
範圍
類型
默認情況下
описание
來源節點
串
與機身相同顏色
從中遷移虛擬機器的計算節點（必要）。
目標節點
串
與機身相同顏色
計算虛擬機器要遷移到的節點。
儲存節點數組元素：
範圍
類型
默認情況下
описание
來源池
串
與機身相同顏色
從中遷移磁碟的儲存池（必需）。
目標池
串
與機身相同顏色
磁碟遷移到的儲存池。
來源類型
串
與機身相同顏色
原始磁碟類型（必需）。
目標類型
串
與機身相同顏色
產生的磁碟類型（必需）。
對象優先元素：
範圍
類型
默認情況下
описание
項目
排列
與機身相同顏色
項目名稱。
計算節點
排列
與機身相同顏色
計算節點名稱。
儲存池
排列
與機身相同顏色
儲存池名稱。
計算
枚舉
與機身相同顏色
虛擬機器參數 [“vcpu_num”、“mem_size”、“disk_size”、“created_at”]。
存儲
枚舉
與機身相同顏色
磁碟參數[“size”，“created_at”]。
採用的方法有虛擬機器遷移、磁碟遷移。
未分類 - 用於促進策略制定過程的輔助目標。 不包含任何規範，並且可以在策略尚未與現有目標關聯時使用。 這個目標也可以作為一個過渡點。 與此目標相關的策略是 Actuator。
制定新目標
觀察者決策引擎 有一個「外部目標」插件接口，可以整合可以使用策略實現的外部目標。
在建立新目標之前，您應該確保現有目標沒有滿足您的需求。
建立一個新插件
要建立新目標，您必須：擴展目標類別、實作類別方法 取得名稱() 傳回您要建立的新目標的唯一 ID。 該唯一識別碼必須與您稍後聲明的入口點名稱相符。
接下來需要實作類別方法 取得顯示名稱() 傳回要建立的目標的翻譯後的顯示名稱（不要使用變數傳回翻譯後的字串，以便翻譯工具可以自動收集它。）。
實作一個類別方法 get_translatable_display_name()傳回新目標的翻譯鍵（實際上是英文顯示名稱）。 傳回值必須與翻譯成 get_display_name() 的字串相符。
實施他的方法 取得功效規格（）返回目標的效率規範。 get_efficacy_specation() 方法傳回 Watcher 提供的 Unclassified() 實例。 此績效規範在製定目標的過程中非常有用，因為它對應於空規範。
→
觀察者架構（更多細節） ).
組件
觀察者API - 實作Watcher提供的REST API的元件。 互動機制：CLI、Horizon 插件、Python SDK。
觀察者資料庫 — 觀察者資料庫。
觀察者應用者 — 執行由觀察者決策引擎元件所建立的行動計畫的元件。
觀察者決策引擎 - 負責計算一組潛在最佳化操作以實現審核目標的元件。 如果未指定策略，元件將獨立選擇最合適的策略。
觀察者指標發布者 - 收集和計算一些指標或事件並將其發佈到 CEP 端點的元件。 該組件的功能也可以由 Ceilometer 發布者提供。
複雜事件處理 (CEP) 引擎 — 複雜事件處理引擎。 出於效能原因，可能有多個 CEP 引擎實例同時運行，每個實例處理特定類型的指標/事件。 在Watcher系統中，CEP觸發兩種類型的動作： - 在時間序列資料庫中記錄相關事件/指標； - 當事件可以影響目前最佳化策略的結果時，向觀察者決策引擎發送適當的事件，因為Openstack叢集不是靜態系統。
組件使用 AMQP 協定進行互動。
→
與Watcher的互動方案
觀察者測試結果
- 在優化 - 行動計劃 500 頁面（無論是在純 Queen 上還是在帶有 Tionix 模組的展位上），它僅在啟動審核並生成行動計劃後才會出現；空的頁面會正常打開。
- 操作詳細資訊標籤上有錯誤，無法取得審核目標和策略（無論是在純 Queens 上還是在有 Tionix 模組的支架上）。
- 正常建立並啟動以虛擬（測試）為目的的審核，並產生行動計畫。
- 不會建立對未分類目標的審核，因為該目標不起作用，並且用於建立新策略時的中間配置。
- 已成功建立用於 Workload Balancing（儲存容量平衡策略）的審核，但未產生操作計劃。 無需儲存池優化。
- Workload Balancing 目標（Workload Balance 遷移策略）的審核已成功創建，但未產生操作計劃。
- Workload Balancing（工作負載穩定策略）審核失敗。
- 已成功建立對「吵鬧鄰居」目標的審核，但未產生行動計畫。
- 用於硬體維護的審核已成功創建，但未完整生成行動計劃（產生效能指標，但未產生行動清單本身）。
- 在計算和控制節點上的 nova.conf 配置（預設部分compute_monitors = cpu.virt_driver）中進行編輯不會修正錯誤。
- 針對伺服器整合（基本策略）的審核也失敗。
- 用於伺服器整合（VM 工作負載整合策略）的審核失敗並出現錯誤。 日誌中取得來源資料時發生錯誤。 錯誤的討論，特別是 .
我們嘗試在設定檔中指定 Watcher（它沒有幫助 - 由於所有優化頁面上都出現錯誤，返回設定檔的原始內容並不能修正這種情況）： [watcher_strategies.basic] 資料來源 = ceilometer、gnocchi - 節能審核失敗。 從日誌來看，問題仍然是缺少 Ironic；如果沒有裸機服務，它就無法運作。
- 熱優化審核失敗。 回溯與伺服器整合（VM 工作負載整合策略）相同（來源資料錯誤）
- 以氣流優化為目的的審核因錯誤而失敗。
也會遇到以下審核完成錯誤。 Decision-engine.log 日誌中的回溯（未定義群集狀態）。
→ 錯誤的討論
結論
經過兩個月的研究，我們得出了明確的結論：為了獲得一個成熟的、可工作的負載平衡系統，我們將在這一部分中密切合作，以完善 Openstack 平台的工具。
Watcher 已被證明是一個認真且快速發展的產品，具有巨大的潛力，充分利用它需要大量認真的工作。
但本系列的下一篇文章將對此進行更多介紹。
來源： www.habr.com