現實世界資源利用

為了提供一些背景知識，Quasar總結了許多有關資料中心資源利用率的真實世界統計資訊（我複製了大部分內容）

• Twitter上的一個生產叢集，具有數千臺伺服器，由Mesos管理超過一個月。
• 群集主要託管面向使用者的服務。即使預留達到總容量的80％，總的CPU利用率始終低於20％。
• 即使檢視單個伺服器，它們的大多數在任何一週內都不會超過50％的利用率。典型的記憶體使用率較高（40-50％），但仍與保留的容量有所不同。
• 很少的工作負載會保留適當數量的資源；大多數工作負載（70％）高估了預留量達10倍，而許多工作負載（20％）低估了預留量達5倍。
• 使用更成熟的Borg系統管理的12,000臺伺服器的Google叢集始終可以實現25-35％的CPU總利用率和40％的記憶體總利用率。相反，預留的資源分別超過了CPU和記憶體可用容量的75％和60％。

Twitter和Google處於使用範圍的高階。對於無法與Google和Twitter分別與Borg和Mesos共同處理工作負載的雲設施，利用率估計甚至更低。

• 各種分析估計整個行業的利用率在6％至12％之間。
• 最近的一項研究估計，Amazon EC2上的伺服器利用率在3％到17％之間。

因此，總的來說，我可以假設現實世界的資源利用率低於20％。太低了

計劃目標

如之前的“能源感知型雲端計算摘要”所述，排程的根本動機是節省能源成本（幾乎佔總支出的50％，其中包括購買新機器）。為了提高資源利用率（或能源效率），排程需要在更少的主機中整合應用程式。但這提出了有關效能和QoS（服務質量）/ SLA（服務水平協議）/ SLO（服務水平目標）的新問題。下面我總結了排程的目標

• 伺服器整合。機器更少，應用密度更高，資源利用率更高，能源效率更高。最終降低成本。
• 提高資源利用率。更高的資源利用率可以提高電源效率，並減少空閒資源的浪費。
• 餘額資源放置是同一枚硬幣的另一面。對於儲存，我們需要兼顧儲存容量空間和訪問熱點空間。但是，對於第二點，基於一致性雜湊的展示位置通常會忽略/不靈活。
• 確保應用程式的QoS / SLA / SLO。有相似的名字。為了一致性，我在下面將其稱為SLA。
• 通過更好的放置來提高預定應用程式的效能

這些目標是相互關聯的。同樣，基本上，將更多的應用程式整合在一臺主機中，提高資源利用率，這自然是針對應用程式SLA的。在排程領域這是一場持續的戰鬥。

儘管如此，排程程式可能還有其他目標，例如下面。所以要保持開放的心態

• 尾部潛伏期。通過巧妙地放置或複製分割槽任務，所有分割槽的最大延遲（尾部延遲）數量將受到限制。同樣，正如所看到的，延遲可能是排程的目標。

計劃的補充部分

我實際上將雲排程理解為三個互補方面

• 常識排程。任務啟動時，排程程式會找到最佳執行位置。
• 例如：Green Cloud，Paragon，Quasar。還有Openstack，Kubernetes，Mesos等等的排程程式。
• 持續優化。當任務已經執行時，我們可以優化其放置。最常見的技術是實時遷移。可以在另一臺主機上移動/重新安排/重新啟動任務。監視是必要的。
• 示例：Openstack Watcher，VMware DRS
• 資源容器（我叫這個名字）。它在本地一個主機級別上工作。它的需求是雙重的，AFAIK遠遠超出了Docker
• 對於位於同一位置的關鍵應用程式和效果最好的（低優先順序）應用程式，我們需要一種隔離其資源大小，隔離其資源頻寬，隔離其資源干擾並最終隔離其效能的方法。
• 另一個方面是，由於工作負載是隨時間變化的，因此資源容器需要動態響應以擴充套件/縮小其氣泡。這樣，盡力而為的應用程式就可以利用關鍵應用程式留下的所有空閒資源。
• 示例：Google Heracles

理想的情況是，它們可以一起作為完整的雲排程解決方案。在現實世界中，通常缺少後兩個。另外，為了提高資源利用率，例如也可以從人/使用者開始。

• 資源定價和退款。它迫使使用者考慮應該租多少錢。金錢激勵提高了資源效率。請參閱Twitter的。

排程因素

我嘗試總結排程應該考慮的所有因素。AFAIK，考慮了更多因素，排程效率更高。

首先，資源。它包括資源大小和資源頻寬。後者更容易忽略。Google Heracles是一個很好的參考。容器名稱空間的隔離僅僅是一個開始。CGroups沒有提供完整的功能。

• CPU：Cpu核心，時間配額，權重
• 快取：L1 / L2 / L3 /上級快取（LLC）（Intel CAT），TLB
• DRAM：記憶體大小，記憶體頻寬；還有NUMA和記憶體節點
• 永久記憶體：大小，頻寬；如果新增到系統
• 磁碟IO：IOPS，每秒請求，磁碟頻寬
• NVM：如果將NVM / NVMe / SSD磁碟視為更寶貴的資源，則可以使用它們
• 網路流量：每秒資料包，頻寬
• PCI匯流排：PCI匯流排頻寬是有限的資源
• 電源：電源病毒可能會降低CPU核心頻率
• GPU：限制使用的大小（核心？內部儲存器？），使用的頻寬等
• 更多的硬體（虛擬）功能：例如壓縮卡，Fathom GPU棒等

另一件容易忽略的事情是

• 隨時間變化。實際的工作量實際上是隨時間變化的，因此需要資源利用。通過恆定的模板/清單（例如，在Openstack，Kubernetes，Mesos中）指定應用程式需要多少總是會浪費一些內部剩餘的資源。

  • 無伺服器，從本質上將應用程式劃分為短期任務，可能會解決此問題。

總體而言，資源干擾是主要問題。如在Paragon中所使用的，Bubble-up提出了一種很好的方法來建模和測量資源干擾

• 為應用建模資源干擾

  • 可以接受：每種資源的單一基準，請檢視其壓力將使應用程式脫離其SLA。它揭示了應用程式對每種資源干擾型別的不同敏感性。

  • 原因：當應用程式在其SLA級別執行時，每種資源會產生多大的壓力。它將充當其他位於同一位置的應用程式上的資源干預。

• 要確定資源的吸引力，請使用氣泡

  • 可以容忍：對於每種資源，請慢慢增加其基準壓力，直到應用程式無法通過其SLA為止。記下這一點作為得分。

  • 原因：讓應用程式僅在其SLA點執行。記錄下每種型別產生的資源壓力。

Paragon＆Quasar揭示，應用程式首選項在很大程度上提高了排程效率，尤其是伺服器配置（即（VM）硬體設定）。他們在上線之前就按階段分析了已分階段的任務，並使用協作過濾來填充缺失的列。

• 偏好資源干擾。不同的應用程式對資源型別的敏感性不同。

• 首選伺服器配置。伺服器配置可能會嚴重影響應用效能

  • 它包括：CPU時脈頻率，插槽，核心，L1 / L2 / L3快取記憶體/ LLC，TLB，記憶體和伺服器硬體的壽命等。

  • 硬體支援也是一個考慮因素。GPU，大記憶體，SR-IOV，NVM或特殊的硬體輔助，加速卡等。

• 傾向於橫向擴充套件和縱向擴充套件。應用程式效能可能對每個應用程式都有不同的敏感性。

下一個因素是應用程式依賴性。應用程式通常依賴於其他應用程式來工作。他們的互動頻率和流量不對稱。統一排程在這裡不合適。應用程式之間變化的親和力導致

• 通過應用之間的流量親緣關係進行排程：頻率，頻寬。

• 應用託管。將高度有限的應用程式放在一臺主機，一個機架中，在同一臺交換機下或任何位置，以縮短其網路距離。

  • 相關：Kubernetes“ Pod ”，適用於Mesos的Netflix Fenzo。

• 單元架構。我們沒有將所有事物放入一個非常大的群集中，而是將它們劃分為多個較小的單元。通常我們可以按使用者對它們進行分割槽。從根本上講，高度依賴的應用程式被劃分到同一單元中，並在同一位置部署。

  • 單元體系結構還執行一種解決簇太大問題的方法。單元可以足夠小以進行設計和管理。實際上，提倡的線性可伸縮性並不總是適用於無限大的群集大小。

  • 示例：網際網路公司中的單元架構（按使用者）：[1] [2] [3] [4]；Azure儲存戳; Openstack Nova Cell。

• 資料區域性性。將應用程式（計算）靠近資料（待計算）。自Hadoop和MapReduce以來，該概念已普及。

另外，應考慮不同的工作負載/任務型別。這是尺寸。Google Omega和Borg顯示了一些方面。

• 服務與批次。服務通常是面向使用者的，對延遲至關重要的並且具有較高的優先順序。批處理通常是Hadoop / Spark / etc，優先順序低，並且按時更靈活。

• 短期任務和長期工作。通常，短期任務和長期工作會受到不同待遇。它們的數量氾濫可能是非常不同的。

• 洪水量。每秒執行多少任務，是重負載還是輕負載。這可能導致不同的策略。

社群的努力是巨大的，但是AFAIK仍然有很多缺失的部分。

排程方法

這是最靈活的部分。這取決於排程程式如何使用上述因素並決定其策略。我總結了一些我知道的

• 貪婪。篩選不合適的主機，找到最合適的主機，然後在其上安排應用。這是最常用的方法，通常足夠有效。

• 約束方程。將排程問題視為求解約束方程。它可以用來表達複雜的業務規則。

• 使用預測。機器學習和智慧分析高度參與。

  • 使用的模型可以是簡單的線性函式，統計模型（PDF）或其他機器學習演算法（例如，Paragon中的協作過濾）。

  • 預測的可能是工作負載模式（例如Netflix Scryer），應用程式首選項（例如Paragon和Quasar），展示位置分佈，違反SLA的可能性……這是無限的。

  • 策略的後設資料。一種排程策略可能並不適合所有條件。排程程式可以配備許多策略，並決定何時切換到什麼。

• 積極主動。決定是對變化做出反應還是對變化採取積極行動會導致採取不同的策略，通常是為了應對變化的工作量。Netflix Scryer就是一個例子。

• 優化問題。將資源的最佳分配視為優化問題，並使用適當的漸變色（例如Google Heracles）。

• 舞臺分析。線上預定該應用之前，我們可以先在幾臺專用計算機上對其進行概要分析。瞭解更多關於它的偏好後，我們可以進行更好的排程。參見Paragon。

• 結合專用問題/用例。例如，移動眾包。這可以得出不同的演算法。

必須始終有新的，更好的方法和更好的方法。敬請關注。

排程架構

正在進行各種排程體系結構。這是很好的參考（及其中文翻譯版本）。

• 整體排程程式。中心排程程式會做所有事情，或者共享同一資料庫的無狀態排程程式的副本。這是一種常見的方法，可以很好地應對工程師的複雜性。在Openstack中看到的大多數排程程式，Kubernetes都是這樣。

• 兩級排程程式。例子是Mesos。它將資源分配和任務放置分開。通常，中央排程程式會分發資源提議，並且每個應用程式都掛在其第二級排程程式上以進行任務放置。

  • 優點：應用程式更容易在二級排程程式中掛接其專用邏輯。資源提供是一個新概念。

    • 最重要的是，Mesos解決了靜態分割槽問題：Hadoop，Spark，Storm等各自佔用自己的資源池，它們每個都有自己的排程程式。但是，由於池分割槽是靜態的，因此Hadoop無法借用Spark的空閒資源，反之亦然。通過Mesos，它們共享相同的資源池。Mesos充當資料中心級別的資源排程程式。

  • 不好的一面：二級排程程式的意見不一。他們看不到全球地位，而只能看到提供給他們的東西。如果沒有全域性性的瞭解，就很容易做出次優的決策，尤其是對於共置任務。

    • 有些作品試圖解決Mesos的問題，例如Netflix Fenzo。

• 共享狀態排程程式。示例是Google Omega。排程程式共享群集的狀態。群集狀態的副本由排程程式獨立更新；它們可能會發生衝突，因此需要樂觀地併發事務。單個排程程式可能正在處理過時的資訊，並且在高競爭下可能會遇到效能下降的情況。

• 完全分散式的排程程式。排程程式是分散式的，它們之間沒有協調。作業可以提交給任何排程程式，每個排程程式都可以將任務放置在群集中的任何位置。它仍然是學術性的。問題在於，以這種方式設計功能全面的綜合排程程式太困難了。

• 混合排程程式。它試圖結合單片計劃程式和共享狀態計劃程式，以解決完全分散式計劃程式的問題。例如，有兩種排程路徑：用於非常短的任務或低優先順序批處理工作負載的分散式路徑，以及用於其餘任務的集中式路徑。它仍然是學術性的。