詳解數倉的網路調度與隔離管控能力

摘要：GaussDB目前采用的FIFO調度機制，該調度機制無法滿足用戶的網路隔離需求和QoS需求，同時FIFO調度可能帶來比較嚴重的抖動，

本文分享自華為云社區《【玩轉PB級數倉GaussDB(DWS)】GaussDB(DWS)網路調度與隔離管控能力》，作者：門前一棵葡萄樹 ，

一、常見的調度演算法

QoS（Quality of Service）即服務質量，是一種調度控制機制，是網路設計和運維的重要技術，在帶寬資源有限情況下，針對不同用戶/業務采用不同的調度策略，為任務提供端到端的服務質量保證，QoS本身并不會拓展帶寬，提升網路吞吐量，相反設計不合理的調度反而有可能降低整體吞吐量，QoS的一個關鍵點是允許不平等的網路調度，降低時延要求低、性能和抖動不敏感的業務調度優先級，優先調度時延要求高、帶寬要求一般不高的業務，

調度器是實作QoS的關鍵，調度器根據優先級和帶寬配比進行業務調度，調度器的輸入是要提供服務的資料包佇列，輸出是完成調度輸出的一個個資料包，調度演算法是調度器的核心，設計調度演算法要充分考慮業務場景和用戶需求，沒有萬能的調度演算法，只有合適的調度演算法，常見的調度演算法有很多，這里我們只簡單介紹GaussDB網路調度涉及的調度演算法：

1.FIFO調度

FIFO(First In Forst Out)調度使用的是FCFS策略，是一種不考慮QoS的調度演算法，FIFO調度不進行報文分類，所有業務共用一個佇列，按照請求進入佇列順序進行調度，如下圖所示，三種不同業務的請求全部加入到一個佇列中，按照FIFO的規則進行調度，

FIFO調度實作簡單、開銷小，但是FIFO不區分請求型別、不考慮QoS，對時延、抖動敏感的業務不友好，無法保證關鍵業務服務質量，

2.SP調度

SP(Strict Priority)嚴格優先級調度嚴格按照佇列優先級進行調度，只有在高優先級佇列中請求全部調度完成的情況下，才會考慮調度低優先級佇列中的請求，如下圖所示，三種不同業務分別對應三種不同優先級的佇列：高優佇列、中優佇列和低優佇列，不同業務的請求分別加入到相應優先級佇列中，調度時優先調度高優佇列請求，高優佇列中請求調度完成后，依次調度中優和低優佇列請求，

SP調度演算法的實作比較簡單，優點是可以保證關鍵業務可以優先調度到，可以最大限度的降低網路延遲和抖動；缺點是網路擁塞，高優先級佇列中一直有請求時，會導致低優先級佇列中請求一直調度不到，出現“餓死”的情況，

3.RR調度

RR(Round Robin)輪詢調度通常采用分時機制，為每個佇列分配一個時間片或調度時刻，RR調度按照固定順序回圈調度每一個佇列中的請求，每次調度相同數量（一般是1個）的請求，且在調度程序中不考慮任何優先級，演算法較為簡單且容易實作，同時不會產生“餓死”問題，如下圖所示，RR調度輪詢調度佇列1/2/3中的請求，每次調度一個佇列中的一個請求，直到請求調度完成，

RR調度假設所有佇列的優先級和帶寬需求都是相同的，調度時不考慮包長、佇列時延和帶寬需求，佇列包長差異比較大時，可能導致不同佇列實際占用帶寬差異巨大，同時因為不考慮時延和帶寬需求，導致無法做到對網路流量的精準隔離和調度，

4.WRR調度

輪詢調度保證了各佇列在請求調度時的公平性，但是無法滿足個性化的調度需求，WRR(Weighted Round Robin)加權輪詢調度在輪詢的基礎上為佇列增加權重，每個佇列設定一個計數器，根據權重初始化計數器初始值，每調度一個報文，計數器減1，權重越大，每次輪詢調度次數越多，能調度的包數量也就越多，如下圖所示，三個佇列權重分別是3:2:1，每一輪調度的包數量比例就是3:2:1，

當所有佇列權重值都是1時，WRR調度退化為RR調度，WRR的優點是可以按比例調度各個佇列的請求，適應性更強，但是由于調度時沒有考慮包長，還是按照請求個數進行調度，在請求長度變化時無法保證各佇列按照設定比例占用帶寬，而用戶一般關心和感知到的是帶寬，此外佇列請求長度不一致時，WRR調度對請求長度較小的佇列帶來不公平性，

5.DWRR調度

為了解決佇列請求長度不一致帶來的不公平性，DWRR(Deficit Weighted Round Robin)差分加權輪詢調度在WRR基礎上，基于請求長度而非請求個數設定權值，按照權重和請求長度進行調度，DWRR為每個佇列設定一個計數器，計數器初始化為weight * MTU，每次調度計數器減去請求長度，具體演算法邏輯如下：

1. 初始化佇列計數器DC = weight * MTU；
2. 調度器輪詢非空佇列，如果佇列DC <= 0，則跳過輪詢下一個佇列；
3. 調度佇列請求，計數器DC = DC - request_len；
4. 所有佇列DC < 0或無請求調度時，DC = DC + weight * MTU，

DWRR調度克服了請求長度變化帶來的不公平性，提供了更為精準的帶寬分配，但是佇列數量較大或者MTU設定較大時，調度器完成一輪調度的時間可能比較長，這樣可能會引發較大的傳輸時延抖動，此外DWRR調度無法滿足高優佇列優先調度的需求，

6. SP+DWRR調度

SP調度可能出現“餓死”問題，同時不能實作帶寬按比例調度；而DWRR調度可以實作帶寬的按比例調度，同時解決了“餓死”問題，但是無法滿足高優業務優先調度的需求，因此結合SP調度和DWRR調度的優點，實作SP+DWRR的調度，調度時優先保證SP調度，在高優佇列無請求調度時，才嘗試調度低優佇列請求，如下圖所示，SP調度高優佇列、低優佇列和普通佇列，佇列優先級為：高優佇列 > 普通佇列 > 低優佇列，

佇列1/2/3按照配置權重值進行DWRR調度，高優佇列、低優佇列和普通佇列間按照SP演算法進行調度，高優佇列無請求調度時，嘗試呼叫普通佇列組內的請求，在普通佇列組內所有佇列均無請求時，才調度低優佇列請求，

二、 GaussDB網路調度

1. 網路調度實作

GaussDB目前采用的FIFO調度機制，該調度機制無法滿足用戶的網路隔離需求和QoS需求，同時FIFO調度可能帶來比較嚴重的抖動，抖動來自兩方面：一方面是不同業務爭取同一佇列引發的入列時延損耗，另一方面是佇列內請求數量變化帶來的調度時延變化，因此為了滿足用戶個性化的網路隔離需求和QoS需求，設計實作GaussDB網路調度，

GaussDB的網路調度有三層需求：

1. 不同資源池間的網路隔離和帶寬配比需求；
2. 高優業務的優先調度需求；
3. 網路欠佳SQL的降級需求，

考慮到以上需求，我們采用SP+DWRR調度演算法設計實作GaussDB的網路調度，同時考慮到佇列數量變化及MTU設定帶來的時延影響，對DWRR調度進行改進，每次獲取最優佇列進行調度（性能損耗較大，但是可以優化改進），

設計實作三種優先級佇列：高優佇列、普通佇列和低優佇列，三種佇列優先級順序為：高優佇列 > 普通佇列 > 低優佇列，三類佇列調度的業務型別如下：

1. 高優佇列用于調度超戶和不需管控查詢的網路請求；
2. 普通佇列用于調度正常需要管控的查詢的網路請求，普通佇列間按照DWRR演算法進行請求調度；
3. 低優佇列用于調度降級查詢的網路請求，

GaussDB基于DWRR實作的網路隔離屬于配額共享的資源隔離，區別于限流的網路隔離，該隔離方案在保障資源池間網路隔離和帶寬占比的前提下，可以最大化地利用網路帶寬，有效降低網路隔離對網路吞吐量的影響，GaussDB配額共享的網路隔離有兩層含義：

• 共享：所有資源池間網路資源共享，網路空閑時，按需調度；
• 配額：網路調度繁忙情況下，按照配置權重比例進行調度，

基于SP調度機制實作的網路降級有以下優點：

• 超戶業務或正常業務有網路請求時，優先調度超戶和正常業務的網路請求，保障超戶和正常業務的QoS；
• 網路空閑，超戶和正常業務調度無請求調度時，降級查詢可以按需占用空閑時間進行網路調度，

SP調度可能出現“餓死”情況，因此一般情況下，用戶在設計網路隔離方案時，不建議有資源池不設定網路管控引數（帶寬權重），此外網路欠佳SQL降級后如果出現“餓死”情況，一般說明網路帶寬資源緊張，需要進行錯峰調度或配置并發管控，

2. 網路隔離應用

考慮一個比較簡單的客戶場景：用戶自定義兩個資源池rp1和rp2，兩個資源池帶寬權重分別配置為4和2，同時配置默認資源池帶寬權重值為1，

ALTER RESOURCE POOL rp1 WITH(WEIGHT=4);

ALTER RESOURCE POOL rp2 WITH(WEIGHT=2);

ALTER RESOURCE POOL default_pool WITH(WEIGHT=1);

配置完成后，在三個佇列都有請求的情況下，rp1、rp2和default_pool會按照4:2:1的比例進行網路請求調度，網路擁塞，三個佇列都有調度不完的請求情況下，rp1占用4/7的帶寬，rp2占用2/7的帶寬，default_pool占用1/7的帶寬，在有佇列無請求情況下，其他有請求的佇列按照權重配比搶占網路帶寬，

設定查詢運行超過20min，且網路帶寬占用超過512MB時降級：

CREATE EXCEPT RULE bandwidth_rule1 WITH(bandwidth=512, ELAPSEDTIME=1200, action='penalty');

設定查詢運行超過30min，且網路帶寬占用超過1GB時降級：

CREATE EXCEPT RULE bandwidth_rule2 WITH(bandwidth=1024, ELAPSEDTIME=1800, action='abort');

資源池關聯例外規則：

ALTER RESOURCE POOL rp1 WITH(EXCEPT_RULE='bandwidth_rule1, bandwidth_rule2');

關聯資源池rp1的用戶執行的查詢，如果運行時間超過20min，且占用帶寬超過512MB時查詢即被降級，降級后該查詢網路請求由低優佇列調度，為了防止報文錯亂，降級不可恢復；如果運行時間超過30min，且占用帶寬超過1GB時查詢即被查殺，

資源池監控視圖集成了網路收發速率監控，可以通過查詢資源池監控對各資源池網路收發流量進行監控：

查詢當前CN/DN上網路收發速率：SELECT rpname,send_speed,recv_speed FROM gs_respool_resource_info;

查詢所有CN/DN上網路收發速率：SELECT nodename,rpname,send_speed,recv_speed FROM pgxc_respool_resource_info order by 1,2;

通過資源池網路監控視圖可以直觀地觀察到資源池網路隔離效果，同時對資源池帶寬權重配置優化配置進行指導，

點擊關注，第一時間了解華為云新鮮技術~

標籤：MySQL

上一篇：ClickHouse(13)ClickHouse合并樹MergeTree家族表引擎之CollapsingMergeTree詳細決議

下一篇：MySQL學習筆記-約束