本文作者
李雨前，阿里雲彈性計算技術專家，有 5 年的大規模集群資源管理調度實踐經驗：針對 long-time service 及 co-location 調度具有全面、深入的一線實踐和解決問題經驗，提交 10+ 項相關發明專利；擅長穩定性優先的集群調度策略和穩定性架構設計、全局穩定性數據分析實踐，以及 Java 和 Go 編程語言。

背景

隨著企業數字化和全面上雲的推進，更多的企業將在雲上生雲上長，雲計算的集群管理調度技術支撐著所有云上業務應用。工程師應該像過去了解操作系統一樣瞭解今天的集群管理調度。雲時代的工程師，需要進一步瞭解這一領域，從而更好地理解雲、利用雲、發揮雲的優勢，贏在雲計算時代。

對於已經上雲的企業，如果想深度管理自己雲上的計算資源，有哪些途徑或者說有哪些實踐方法呢？求解的朋友們，請看下文。在正式介紹之前，先概要介紹下相關概念，幫助大家更好地理解後面的內容。

ICR

立即生效容量預定（Immediately Capacity Reservation）。您可以隨時購買立即生效容量預定，預訂成功後立即生效，即容量被鎖定。購買立即生效容量預定時設置可用區、實例規格、操作系統類型等屬性，系統會以私有池的方式預留屬性相匹配的資源。在創建按量付費實例時選擇使用私有池的容量，即可提供資源確定性保障。無論是否使用預定容量創建了實例，生效後即開始按照按量實例費率收費，直至立即生效容量預定被釋放。

ROS

阿里雲資源編排服務（Resource Orchestration Service ）是一種簡單易用的雲計算資源自動化部署服務。用戶可以通過使用 Json/Yaml 格式的模版描述多個雲計算資源（如 ECS、RDS、SLB）的配置、依賴關係等，並自動完成所有云資源在多個不同地域以及多個賬戶中的部署和配置，實現基礎設施即代碼（Infrastructure as Code）。

OOS

阿里雲運維編排服務 OOS 是一個全面的雲上自動化運維平臺，提供了運維任務的管理和執行。使用場景有：事件驅動，批量操作，定時運維任務，跨地域等，OOS 特別為重要的場景提供了審批、通知等功能。OOS 支持跨產品使用，您可以使用 OOS 管理 ECS、RDS、SLB、VPC 等雲產品。

Auto Scaling

使用彈性伸縮（Auto Scaling），您可以根據業務需求和策略設置伸縮規則，在業務需求增長時自動為您增加 ECS 實例以保證計算能力，在業務需求下降時自動減少 ECS 實例以節約成本。彈性伸縮不僅適合業務量不斷波動的應用程序，同時也適合業務量穩定的應用程序。

DDH

專有宿主機（Dedicated Host）是阿里雲專為企業用戶定製優化的解決方案。具有物理資源獨享、部署更靈活、配置更豐富、性價比更高等特點。專有宿主機為單租戶獨享物理資源，作為該雲主機的唯一租戶，您不需要與其他租戶共享雲主機所有物理資源。同時宿主機上可以靈活創建 ECS 雲服務器，並和其他 ECS 雲服務器一樣，可以掛載雲盤，可以通過 VPC 聯通，具有高度的靈活性和使用便捷性。

上雲後，資源調度的必要性

上雲後，我的資源調度有必要自己做不？這個問題首先需要評估清楚。上雲後，企業內部圍繞業務的研發投入始終是企業最關鍵的研發投入。如果企業再投入人力研發雲上資源調度，等於增加了研發成本，此時就需要評估投入成本和帶來的效益是否匹配。一般需要從以下幾個方面綜合評估。

資源規模有多大

這個規模非常直接，就是看自己在雲上運行的 ECS 實例個數有多少。如果資源數量較少，完全沒有必要引入自己的調度。這個數量多少，業界暫沒有統一的標準。不同的雲平臺資源服務能力、企業內部 SRE 專業技能、SRE 的依賴工具、IT 環境成熟度各不相同，很難給出一個準確的參考值。我們先假設一個數字 1000，當小於 1000 臺的雲上 ECS 資源，可以藉助阿里雲的 ROS 資源編排或者 OOS 運維編排或者 Auto Scale 彈性伸縮服務進行資源管理。當大於 1000 臺雲上 ECS 資源的時候，可以考慮進行雲上資源的自研資源編排服務。

資源成本壓力有多大

這裡的資源成本壓力特指：已經在雲上保有一點規模的計算實例資源，並且業務還在呈現快速的發展勢頭，對雲上資源的需求量在持續的增加。例如雲上的計算實例個數已經達到 5000。業務應用 App 數量也超過了 100 多個。此時，精細化管理 5000 以上的雲上實例，期望通過合適的混合部署，節約計算實例的成本，以及優化業務編排提升業務穩定性。

資源調度的管理人員是否準備就位

如果企業想對自己雲上資源進行精細化調度和管理，這就需要企業招聘、培養屬於自己的資源調度和管理同學。

上雲後，資源調度的可行性

不上雲的時候，我們的資源調度是怎麼做的呢？先回顧下，一個最簡單、直接的調度系統運行起來，需要哪些基本的職責模塊。如圖 1 所示，我們理解最簡單直接的調度系統模塊有：資源請求 API 模塊、中心調度器模塊、數據庫模塊、物理機結點模塊。

圖1 - 簡單直接的調度模塊構成

其中，資源請求 API 負責對我提供資源創建、啟停等服務。中心調度器負責讀取數據庫中物理機資源信息，進行資源的分配扣減、回收增加等，數據庫負責存儲調度依賴的各種數據，包括物理機的資源信息。物理機結點模塊，主要是響應調度器的請求，執行資源創建或者釋放或者啟停的指令。並將處理後的數據寫入數據庫。

對照上面圖 1，上雲後，相關的模塊是否還可以工作呢？答案是可以的。只是需要做一些適配。目前所有的雲平臺供應商，對外不提供物理機信息的，只提供虛擬化的計算實例的資源信息。

上雲後，繼續資源調度的主要適配點：

（1）數據庫裡存儲的資源信息，需要從雲平臺的 OpenAPI 獲取。

（2）資源信息的維度稍有變化，原來直接可見的物理機，上雲後，需要感知地域 Region、可用區 Zone、雲上網絡 VPC、雲上安全組 SecurityGroup 等信息。

（3）執行指令的接口也發生了變化，原來直接連接內部協議進行資源的操作，在雲上需要將資源操作指令，最早轉換為 OpenAPI 進行資源操作。

以上是基於最簡單的資源調度的模塊介紹，實際生產中會相對複雜一些，模塊也會多一些。例如資源的監控、資源數據的初始化和更新等。例如異常資源結點的自動替換。

上雲後，資源調度的實踐方案

繼續基於最簡單的資源調度模塊，以及目前雲上提供的資源數據和資源操作 API，我們來看看實踐過程，有哪些方案，各自有哪些優缺點。

目前雲上的計算資源的形態多樣。例如阿里雲提供廣泛的、適合各種業務場景下，特定 Workload 的計算實例，也提供了專有宿主機計算實例，還提供了私有池服務（CR Capacity Reservation 容量預留，適合進行雲上的容量規劃、雲上的資源確定性等場景。例如 ICR 理解容量預留）。下面介紹下企業基於以上三種雲的資源售賣形態進行資源調度的實踐方案。

基於通用的 ECS 計算實例的企業雲上資源調度

基於通用 ECS 計算實例的企業雲上資源調度（最小集）如圖 2 所示，其中資源數據庫部分，資源數據來源 ECS 計算實例，圖 1 中的物理結點替換為 ECS 計算實例，圖 1 中的操作指令依然是內部協議。這個場景下，強依賴的能力模塊有：

圖2 - 基於ECS計算實例的企業雲上資源調度

• 能力模塊 1: 業務支持容器化部署

在圖 2 所示，資源分配執行的結點是 ECS 實例。在 ECS 實例上繼續進行資源分配，典型的就是多容器運行在同一個 ECS 實例上。當 ECS 實例規格很大，例如 vCPU （virtual CPU）核數為 32，此時，CPU 能力等於傳統的一個 32 vCPU 的物理機算力了。

• 能力模塊 2: 動態擴縮 ECS 實例數量

在圖 2 所示，企業自行調度的雲上資源池規模就是已購買的雲上 ECS 實例構成的資源規模。

優勢：

企業自主、細粒度控制不同 ECS 實例規格類型、ECS 實例數量、ECS 實例地域分佈等信息，從而結合業務Workload特徵，針對性地購買 ECS 實例，針對性地編排部署容器實例。

典型的也可以直接交給雲平臺的容器服務來託管。例如阿里雲的 ACK 服務，進行容器服務託管。

劣勢：

需要事先購買 ECS 計算實例。這裡是說要先購買 ECS 計算實例，然後這個 ECS 實例才會進入企業雲上調度的資源數據庫。比較省成本的做法，只在需要的擴充資源池的時候，才購買 ECS 計算實例，而不是事先批量購買 ECS 計算實例。批量事先購買，但是實際沒有使用的話，就產生了資源浪費。

另一個是，只支持容量操作的內部協議。

適合的場景：

企業業務規模大，不同業務間負載不同，業務已應用容器化部署；

專職資源調度管理的同學、對雲上資源成本有優化訴求的企業。

基於專有宿主機計算實例的企業雲上資源調度

基於專有宿主機（DDH）計算實例的企業雲上資源調度（最小集）如圖3所示。其中資源數據庫部分，資源數據來源 DDH 計算實例的資源。

圖3 - 基於 DDH 計算實例的企業雲上資源調度

圖 1 中的物理結點替換為 DDH 計算實例，圖1中的操作指令由內部協議，改為 OpenAPI 協議（也支持容器的內部協議）。這個場景下，強依賴的能力模塊有：

• 能力模塊 1: 動態擴縮 DDH 實例數量

圖 3 所示，企業自行調度的雲上資源池規模就是已購買的雲上 DDH 實例構成的資源規模。

優勢：

企業自主、細粒度控制不同 DDH 實例規格類型、DDH 實例數量、DDH 實例地域分佈等信息。從而結合業務Workload特徵，針對性地購買 DDH 計算實例，針對性地編排部署容器實例或者 ECS 實例。

支持容器的高密度部署，同時也支持通用的 ECS 實例部署，以及 DDH 上自定義 ECS 實例部署。

劣勢：

需要事先購買 DDH 計算實例。這裡是說要先購買 DDH 計算實例，然後這個 DDH 實例才會進入企業雲上調度的資源數據庫。比較省成本的做法，只在需要的擴充資源池的時候，才購買 DDH 計算實例，而不是事先批量購買 DDH 計算實例。批量事先購買，但是實際沒有使用的話，就產生了資源浪費。

由於 DDH 計算實例規格是整個物理機，所以 DDH 計算實例單個的成本相對 ECS 計算實例較高。並且 DDH 單個容量較大，相同資源池規模下，DDH 結點數就比 ECS 少，一定程度上導致 DDH 上部署的密度會比 ECS 大。

適合的場景：

對安全法規有苛刻要求的業務。DDH 可以最小化被管控的物理結點規模，減少規模的風險；

對軟件版權有苛刻要求的業務。DDH 上 license 的費用可以分攤到多個業務實例上；

對性能有極致要求的業務。DDH 可以實現本地化訪問，獲取極致響應時間；

超大規模的資源訴求，並且有專業的資源調度和管理部門。

基於私有池的企業雲上資源調度

基於私有池的企業雲上資源調度（最小集）如圖4所示。其中資源數據庫部分，資源數據來源私有池計算實例的資源。

圖4 - 基於私有池的企業雲上資源調度

對比圖1中的物理結點替換為私有池，圖1中的操作指令由內部協議，改為 OpenAPI 協議。這個場景下，強依賴的能力模塊有：

• 能力模塊 1: 動態擴縮私有池對應的容量

在圖 4 所示，企業自行調度的雲上資源池規模就是動態擴容或者縮容指定已有私有池容量或者新增或者釋放私有池。

優勢：

企業自主、細粒度控制容量，進行雲上容量的規劃和分配。將原來直接對資源的感知轉化為對容量的感知。更符合業務的發展訴求；

面向私有池同時保留了資源的特性，又支持了面向業務的容量或者算力的規劃；

私有池的費用更加有競爭力，當不使用的時候，私有池剩餘容量可以共享給其他用戶，也可以繼續保有，支付低折扣的剩餘容量費用；

相比 ECS 計算實例、DDH 計算實例，私有池容量一旦預定成功，後面 100% 資源交付成功。而前者 ECS、DDH 在發生資源大量購買的情況下，會出現小概率的因為庫存不足，導致購買失敗。

劣勢：

需要企業實時規劃雲上容量的變化趨勢，從而準實時規劃私有池容量。目前雲平臺也提供容量預測的服務，幫助企業更精準的進行容量規劃；

相比 ECS 計算實例或者 DDH 實例的事先創建好，私有池是實時創建 ECS 實例，有一些些“延時”，幾乎可以忽略。

適合的場景：

對成本和靈活性有極大訴求的企業，並且具備成熟的基礎技術能力來快速擴容部署業務；

有專職的資源調度管理同學、對雲上資源成本有強烈優化訴求的企業。

總結

上雲後，企業依然可以進行雲上資源的精細化調度，並且可以針對企業的實際情況，選擇適合自己的資源管理模式。我們推薦基於容量預定的雲上資源調度。除了滿足精細化資源調度，同時保障資源的 100% 交付，以及長期使用下的折扣優惠。

更多關於資源調度和管理的相關知識介紹，可以參考書籍《深入集群-大型數據中心資源調度和管理》。

關注公眾號“彈性計算百曉生”，後臺留言分享你對“雲上資源調度”的想法。留言的內容可以但不限是，你對“雲上資源調度”的實戰經驗論；避坑小感悟；亦或是你在“雲上資源調度”中遇到的難點困境，均可分享。╰(￣▽￣)╭

後臺將挑選兩條優質留言，送上阿里雲彈性計算技術專家李雨前老師的《深入集群-大型數據中心資源調度和管理》一本。本週五開獎~