本文作者
李雨前，阿裡雲彈性計算技術專家，有 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% 傳遞，以及長期使用下的折扣優惠。
更多關于資源排程和管理的相關知識介紹，可以參考書籍《深入叢集-大型資料中心資源排程和管理》。
關注公衆号“彈性計算百曉生”，背景留言分享你對“雲上資源排程”的想法。留言的内容可以但不限是，你對“雲上資源排程”的實戰經驗論；避坑小感悟；亦或是你在“雲上資源排程”中遇到的難點困境，均可分享。╰(￣▽￣)╭
背景将挑選兩條優質留言，送上阿裡雲彈性計算技術專家李雨前老師的《深入叢集-大型資料中心資源排程和管理》一本。本周五開獎~