摘要：排程演算法是排程器的核心，設計排程演算法要充分考慮業務場景和使用者需求，沒有萬能的排程演算法，只有合適的排程演算法。
本文分享自華為雲社群《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，每次排程計數器減去請求長度。具體演算法邏輯如下：
- 初始化佇列計數器DC = weight * MTU；
- 排程器輪詢非空佇列，如果佇列DC <= 0，則跳過輪詢下一個佇列；
- 排程佇列請求，計數器DC = DC - request_len；
- 所有佇列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的網路排程有三層需求：
- 不同資源池間的網路隔離和頻寬配比需求；
- 高優業務的優先排程需求；
- 網路欠佳SQL的降級需求。
考慮到以上需求，我們採用SP+DWRR排程演算法設計實現GaussDB的網路排程，同時考慮到佇列數量變化及MTU設定帶來的時延影響，對DWRR排程進行改進，每次獲取最優佇列進行排程（效能損耗較大，但是可以最佳化改進）。
設計實現三種優先順序佇列：高優佇列、普通佇列和低優佇列。三種佇列優先順序順序為：高優佇列 > 普通佇列 > 低優佇列。三類佇列排程的業務型別如下：
- 高優佇列用於排程超戶和不需管控查詢的網路請求；
- 普通佇列用於排程正常需要管控的查詢的網路請求，普通佇列間按照DWRR演算法進行請求排程；
- 低優佇列用於排程降級查詢的網路請求。
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;
透過資源池網路監控檢視可以直觀地觀察到資源池網路隔離效果，同時對資源池頻寬權重配置最佳化配置進行指導。