技術探索

虛擬化平台效能監控、分析、與優化系統

2022-04-22

工業技術研究院 資訊與通訊研究所 謝宜玲 李育緯

隨著容器（Container）技術的蓬勃發展，第五代行動通訊（5G）的發展方向已從原先基於虛擬機（Virtual Machine）架構的Virtual Network functions （VNF）朝向容器化的Container Network Functions （CNF）邁進[1][2]。與傳統虛擬機相比，容器的實體資源使用率更高，意即相同的硬體運算資源能夠提供更高的服務品質。此外容器具有輕量化、部署速度快及彈性高的優勢，更適合未來雲原生（Cloud Native）服務應用。同時，為使整體服務獲得良好效能，需要能夠因應服務需求並善用資源，不斷調校達到最佳化配置。然而此調校過程是十分複雜的，維運人員需具備專業知識，熟悉資源分配與服務程序效能的關聯性，並持續進行檢視與動態調整，如此將會花費大量人力時間。因此，工研院開發了一套效能監控暨最佳化軟體，能夠動態監控虛擬化平台上各個應用服務的運作效能，並且自動持續進行監控與優化，藉此可大幅節省人力負擔與維運管理成本。

精彩內容

1. 效能監控與優化手法
2. x-advisor效能監控與優化系統
3. CPU效能最佳化排程演算法
4. CPU使用率之QoS保證技術


效能監控與優化手法 

效能監控 

維運人員通常會監控資源使用率、網路效能及IO效能…等來調校及優化系統效能的運作，其中資源使用率如CPU使用率（CPU Utilization）與Memory使用量，目前有許多工具像Prometheus、Zabbix等可協助蒐集。而網路效能的指標，如延遲時間（Latency）、吞吐量（Throughput）等，因OS或NFVi平台無法直接取得，需服務本身有加以統計這些數據。

以服務體驗的角度，幾個較知名的監控策略如Google’s Four Golden Signals [3]、RED Method [4]、USE Method [5]，所提出的監控指標包括如Rate – 每秒可處理的服務請求數、Error – 每秒失敗的服務請求數、Duration – 一則服務請求所耗的時間、Saturation – 無法及時被處理而被佇列的服務請求數量的比例…等。透過監控上述指標，當發現效能表現有所異常時，即可通知系統管理人員加以關注。

 

效能優化手法 

1. 直接利用硬體及OS所提供的配置設定，來達到增益CPU或Process效能的目的。例如：

  • 指定部分CPU Cores為Isolated，用以配置給特定的Process以獨享該Core，確保該Process的效能。
  • 依照NUMA （Non-Uniform Memory Access）架構，將相關的Processes配置於位在同一個NUMA Node的Cores，避免Cross NUMA Node的效能耗損。
  • 提高Process的Priority，例如使用Linux的Renice指令。
  • 其他各種運算加速技術，例如Hyper Threading功能，可於BIOS中開啟設定。

2. 針對某個服務，遍歷找出其最佳的設定組合，包括該服務本身的參數設定及資源使用量的設定等。遍歷的方式包括梯度下降法（Gradient Descent）, 隨機搜尋（Random Search）、貝葉斯優化（Bayesian optimization）、暴力法（Brute Force）…等等 [6][7]。

 

 

x-advisor效能監控與優化系統 

一般來說，效能監控系統當偵測到效能低落或異常時會發出通知警示系統管理者，再人為介入查看系統狀態進行因應處理。而工研院研發的x-advisor是閉環式的效能監控與優化系統，可自動持續監控系統運行狀態並優化程序（Process）與CPU之排程，自動提升整體效能。其架構如圖1。首先，ConfigChecker模組會檢查基礎之系統環境設定，如Isolated Cores配置是否正確。接著圖中閉環（Closed-loop）的部分，會持續監控CPU Utilization資訊、透過排程演算法計算出更佳之Process-CPU配置方式、然後執行部署該配置。


圖1 x-advisor系統架構圖

x-advisor包含了三項功能：

功能一：檢查環境配置 

x-advisor的ConfigChecker模組可檢查環境中的資源配置是否正確，針對在開機設定這類屬於靜態的部分，目前提供了Isolated Cores的配置檢查。5G服務平台中，通常會選擇將CNF部署於Isolated Cores，確保CNF充分獲得CPU運算資源。此外，對於採用NUMA架構的伺服器，可以安排彼此相關的服務所使用的CPU Cores是位在同一個NUMA Node下，可發揮NUMA架構的最佳效益。因此x-advisor的ConfigChecker模組也提供了NUMA CPU Core拓樸的檢視（如圖2），以Core 0為例，它本身是Physical Core，由於開啟了BIOS裡的Hyper Threading功能，所以它產生了4個Logical Core 0,24及1,25，分別屬於NUMA Socket 0及Socket 1。而Logical Core前方有標星號者代表有被指定為Isolated Core，例如Logical Core 2,26。

 


圖2 NUMA CPU Core拓樸檢視

功能二：檢視Pod-Container-Process之CPU使用情形 

Kubernetes平台本身並未提供顯示Pod或Container所使用的CPU Utilization資訊，Linux所提供的Top等指令只能顯示Process層級的資訊，系統管理者無法掌握CNF的CPU使用狀況。因此x-advisor的GetUtil模組將資訊加以整合，除了能夠取得Process的CPU使用率資訊（如圖3），並取得Pod、Container、Process之間的關係，可組成Top-Down與Bottom-Up兩種View來觀察各Process的CPU Core的配置及使用率之情形（如圖4）。

 


圖3 CPU使用率資訊檢視


圖4 Pod-Container-Process資訊檢視

功能三：CPU效能最佳化 

x-advisor的Scheduler模組會透過GetUtil模組，定期取得當前各Core及各Process的CPU Utilization值，然後利用下一節所介紹的排程演算法找出各Process應配置於哪個Core、及各Process應調整的Priority，使整體獲得最高的CPU使用率，如此持續調整保持最佳化。

 
 

CPU效能最佳化排程演算法

x-advisor所採用的CPU排程演算法包括兩部分：
（1） Greedy演算法
（2） Niceness Tuning，前者的目標是Process-Core配置之最佳化，後者的目標是Process-Priority配置之最佳化。

Process-Core配置最佳化 — Greedy演算法

在Linux Kernel預設的CPU排程機制下，所有的Processes會不斷動態的改變所使用的Core，也可以選擇指定Process固定使用哪個Core，則可有效減少Context Switch而提升運作效能。因此我們設計了Greedy演算法來安排各個Process使用哪個Core，讓各Core的CPU Utilization愈平均愈好。

Greedy演算法的目標是將最忙碌的Core Loading最小化，因此作法是將各Process Loading值從大到小做排序，依序放置到Loading最輕的Core上。由於Process Loading可能會隨機變動，因此需定時檢查各Core CPU Utilization的Variance是否收斂，若超過閥值就再排一次。圖5是經過Greedy演算法排程後的CPU Utilization資訊，共有50個Processes分布在10個Cores，給予各Process的CPU Workload介於5,10,15,20,25％。例如圖中第一欄c21代表Core 21，其下列出此Core內各Process的 CPU Utilization。圖5 (a) 與(b)可見交由OS排程跟使用Greedy演算法排程的差異。(a) OS排程：各Core Utilization大小不一差異大，且Processes會不斷變動換Core，(b) Greedy演算法排程：各Core Utilization較為平均，且各Process所配的Core是固定的，減少Context Switch的消耗。

 


圖5 OS與Greedy演算法排程之比較

由於實驗顯示出Run-time時的CPU Utilization經常會略小於原始Workload，雖然各Core內的Process Workload總和是在100％以內，也就是理論上CPU足以承載，但實際上Workload較重的Process會遭受較大的壓抑。如圖6中，下方黃色字體是Process Workload，Core 16上的兩個Process Workload分別是30％及60％，而實際運行時分別是30.69％及56.11％，顯示Workload較重者會受壓抑。如果各Processes的Workload一樣，如Core 12上的3個Process Workload跟實際運行所達都是30％，就沒有發生短少的現象。在Core 18及Core 20，也可以看到大小不均時，重的Process明顯受壓抑的現象。


圖6 Core內Workload高的Process無法充分獲得CPU資源


從圖6的觀察中發現，當同一個Core上有不同Workload的Process時，會呈現類似Round Robin的運作趨勢，Loading最低的優先滿足後，逐步滿足Loading次低的，Loading最高的Process不見得能充分使用到其所需的CPU Utilization資源。

Process-Priority配置最佳化— Niceness Tuning 

當Core裡Process Workload輕重不一時，為何無法讓各個Process皆能充分獲取所需的CPU Utilization，值得進一步研究。Linux Kernel預設採用的是CFS （Completely Fair Scheduler）演算法，它會累計各個Process的運行時間vruntime，vruntime愈低的會被放在紅黑樹（如圖7）中愈靠近左下角的位置，可較早獲得CPU執行權，CFS便是藉此達到使各個Process公平獲得CPU的目的。

 


圖7 Linux Kernel的CPU Scheduler所使用之紅黑樹

CFS演算法的主要計算公式：

  • slice = 調度周期 * 進程權重 / 所有進程權重之和
  • vruntime+ = 實際運行時間 * 進程優先序所對應之權重 / 進程權重 （優先序與權重之對應關係，如圖8）


圖8 CFS演算法進程優先序與權重之對應

然而CFS演算法會使得Workload較重的Process在紅黑樹中可能被排到優先序較低的位置，故可透過調整Process Priority使其Slice長度同Workload的比例，即可改善此問題。Linux OS中是以Nice值（Niceness）指定Process Priority，圖9 為實驗各種不同的Process Workload組合，經適當調整Niceness後，各Process的Run-time CPU Utilization可非常接近原始Workload。


圖9 透過調整Niceness使各Process的Run-time CPU Utilization皆能接近預期值

綜合以上Greedy演算法及Niceness Tuning方法，x-advisor會定期以Greedy演算法讓Processes平均分佈於各Core，避免Core發生過載或過輕等效能不彰的情況，再針對各Core以Niceness Tuning使各Core內的Processes充分獲得CPU資源。

x-advisor排程效果可接近理論值 

x-advisor也將排程過程同步記錄到資料庫，然後透過Kubernetes Grafana [8]圖像化顯示。以下實驗共運行了50個Processes分布在10個Cores，給予各Process介於5,10,…25％等大小不同的CPU Workload，總Workload為750％，故平均而言每個Core是75％。一開始各Core分配到5個Process （由OS排程），然後透過x-advisor優化調整，在3~4分鐘以內可將總體CPU使用效率提升至期望值（最佳解） ，如圖10所示。

 


圖10 x-advisor排程可使個別CPU Core使用率優化至期望值

圖11可進一步說明效能推進的過程：
1. 由Linux Kernel排程（CFS演算法），效能僅68~69％。
2. x-advisor以Greedy演算法調整讓各Core的負載相近。
3. x-advisor開始對各Process做Niceness Tuning。在16:46:56時，將所有Processes一齊做一次調整，效能明顯上升，達72.8％。
4. x-advisor逐一對每個Core裡的各個Process做Niceness Tuning優化，效能獲得進一步提升。
5. 到16:52:00時，各Core都優化了，達到理論值75％，並維持在>=75％的表現。


圖11 x-advisor排程優化過程

檢視各個Process的效能優化過程，如下圖12，同圖11的歷程。起初受壓抑的高Loading Processes，經優化調整後，都可達到預期CPU Utilization。


圖12 個別Process的CPU 使用率優化過程

上述範例是測試施予10個CPU總Workload 750％，結果顯示x-advisor順利將平均CPU Utilization優化至期望值75％。若Workload更高，只要在不致於讓CPU過載的情況下，例如平均CPU Utilization期望值是95％，則x-advisor同樣能將CPU Utilization優化至該期望值。

CPU使用率之QoS保證技術

藉由設定Process的Niceness，還可運用在QoS，保證各Process可獲得之CPU Utilization：

  • 當有Process的CPU Utilization暴增時，不會影響其他Process的權益，其他Processes仍可獲得被保證的CPU Utilization。
  • 若CPU Utilization並未滿載，則可允許Process的CPU Utilization超過QoS保證量，讓Process充分使用CPU資源。

例如：有3個Processes A,B,C，各別的QoS指定為40％,50％,10％。當其Run-time Workload是40％,50％,80％時，則Process C只能獲得10％；但若Process A不使用CPU資源時，則Process C可獲得40％ - 50％的CPU資源（比Process C 的QoS保證量還多） 。

根據CFS演算法，Process Weight對應了可獲得多少CPU Time （CPU使用率），所以我們可透過設定Process的Niceness來指定Weight，Nice跟Weight是一對一可事先製表，Run-time時查表得知。以下實驗顯示透過指定Niceness可達到QoS保證之CPU Utilization，見圖13。如test1中，Task 1,2,3各別的QoS指定為40％,50％,10％，而Workload是40％,50％,30％，若由OS排程則CPU Utilization都是30％，無法滿足QoS需求，但若經適當調整Niceness，則CPU Utilization分別可達到39％,49％,8％，也就是符合上述指定的QoS。而test2中，同樣可見Task 1,2,3獲得的CPU Utilization經由調整Niceness皆能符合QoS，接著若Task 1不使用CPU資源，只剩Task 2,3，則Task 2的QoS仍被滿足（Workload 50％,QoS 50％,實際獲得49％），而Task 3不僅QoS可滿足，且得以充分使用CPU資源因應目前較高的Workload （Workload 80％,QoS 10％,實際獲得50％）。

 


圖13 CPU使用率之QoS保證技術驗證實例

 

結論 

5G專網虛擬化平台中，為優化整體服務效能，需要持續進行監控、動態調整服務程序與資源之配置，如此將花費大量人力時間。x-advisor軟體，會自動對各個服務進行監控與優化，可大幅節省維運管理成本。x-advisor能在3~4分鐘以內將總體CPU使用效率提升至理論最佳值。x-advisor會定期取得CPU Utilization資訊，以Greedy演算法讓Processes平均分佈於各Core，避免Core發生過載或過輕等效能不彰的情況，再針對各Core以Niceness Tuning調整各Process，將CPU Utilization提升至理論值。藉由設定Process的Niceness，還可運用在QoS，保證各Process可獲得之CPU Utilization。當有Process的CPU Utilization暴增時，不會影響其他Process的權益。若CPU Utilization並未滿載，則可允許Process的CPU Utilization超過QoS保證量，讓Process充分使用CPU資源。

 

參考文獻 

[1] 電腦與通訊（178期） 5G NFVI虛擬化平台技術 [online]. Available: https://ictjournal.itri.org.tw/Content/NewsLetter/contents.aspx?MmmID=654304432137072605&MSID=1036010466630741474
[2] Red Hat, Inc. （2021） VNF and CNF, what's the difference? [online]. Available: https://www.redhat.com/en/topics/cloud-native-apps/vnf-and-cnf-whats-the-difference
[3] Rob Ewaschuk and Betsy Beyer （2017） Monitoring Distributed Systems [online]. Available: https://sre.google/sre-book/monitoring-distributed-systems [6] Tom
[4] Wilkie （2017） The RED Method [online]. Available: https://www.slideshare.net/kausalco/the-red-method-how-to-instrument-your-services
[5] Brendan Gregg （2012） The USE Method [online]. Available: https://www.brendangregg.com/usemethod.html
[6] Y. Shi, Z. Peng, R. Wang and Z. Bian, "Adaptive Cloud Application Tuning with Enhanced Structural Bayesian Optimization," in Proc. IEEE International Conference on Cloud Computing Technology and Science, 2019, pp. 1-8
[7] P. Mercati et al., "MOBO-NFV: Automated Tuning of a Network Function Virtualization System using Multi-Objective Bayesian Optimization," in Proc. IFIP/IEEE International Symposium on Integrated Network Management, 2021, pp. 90-98
[8] Grafana Labs（2014） [online]. Available: https://grafana.com/

 

回上一頁 友善列印