223
阿裏媽媽MaxCompute架構演進史 - AON(MPI)集群
阿裏雲數加MaxCompute （原名：ODPS；https://www.aliyun.com/product/odps）
1.1 MPI集群
1.1.1 背景
我們的集群規模不斷地在加大， 17財年時我們的機器規模預估1.5W台
與此同時我們卻有著不同的感受，明顯感覺到了各種任務的運行效率都在變低，主要問題如下
1.1.2 問題
問題1：
說明
Aon：all-or-nothing
FIFO/Fair：調度係統支持的兩種調度策略
問題2：
問題3：
以上三個問題其實主要原因還是aon類任務跑不起來，但同時卻占著大量的資源給不了別的任務用；
1.1.3 項目目標
最終的想法其實也很簡單，就是拆出獨立AON（但大家習慣了歪叫成MPI）集群，建設規模要達到6000台+，讓且僅讓所有的生產和實驗aon任務（主要是PS和Xlib-mpi）跑在這個上麵，盡量減少Aon任務攢資源引起的資源浪費。
1.1.4 項目收益
1.1.5 關鍵問題及解法
這個看似簡單的結論卻藏著一堆的問題要解
- 關於混合機型；
像MaxCompute這種分布式計算平台的初衷是希望對用戶屏蔽掉底層的物理細節的，在MR/Sql這種單instance對資源需求量（1Core + 2~3G）不是很大的情況下是基本成立的，但在這種大的PS任務情況下，發現這個問題很不好搞，AY87B上是混布的s10(128G + 32Core)和N41(192G + 64Core)，而一個大的AON任務如PS的Server和Worker單個instance動不動就需要40~50G的資源需求量，你說是設置成50G好還是60G好，用戶需要兼顧底層多種機型設置的同時還要考慮任務的執行效率，這給開發同學造成了很大的困擾，因此我們做的第一個決定就是統一aon集群機型，全部使用的是s10係列。
這裏麵實際還有另外一個問題：用s10還是N41？，考慮到兩個我們選的s10，一是LR類迭代任務每輪迭代之後的網絡通信量大，在同是萬M網卡的情況下我們期望單機的Instance越少越好；二是當時的情況是s10機型為主，騰挪起來方便；
這裏關於機型選擇的問題我覺得主要還是網絡IO資源能不能納入資源隔離的問題，如果能很好地控製網絡的使用那麼機型本身也就不是個多大的問題了。
- 計算資源量儲備
從單機來看，由於單個Instance的資源需求量大，很容易造成一個現象：“資源碎片”，經常出現20G以上的大“碎片”
從任務來看，獨立集群的意義主要在於能讓AON任務快速拿到資源，避免掉“攢”資源的過程，所以我們基本會按照需求的130%做資源準備
- 資源利用率和調度策略
由於大碎片和超額的資源配置，集群利用率肯定就不會太高，因此如何把這部分資源用起來就是一個不得不解的問題；
這個時候主要靠的就是全局調度、超賣和搶占了
【全局調度】：顧名思義就是在多個集群間做資源負載均衡的，幹的事主要就是當MR集群壓力大時且AON集群有空間時將部分MR任務導到AON集群；
但這種做法和以前的做法貌似差別不大，最終也會是MR和AON混跑造成相互影響，唯一好處就是能保證AON是盡量最閑的，因此我們不得不再次升級策略：搶占
【搶占】
搶占的前提是優先級，目前MaxCompute的任務優先級由project的優先級和job的優先級組成，跑在阿裏媽媽AON集群上的任務有三大類：線上AON/實驗AON/MR(含sql)，他們的優先級通常是遞減的。
搶占從粒度上分主要有兩種：Quota組間的搶占和Quota內的搶占
從力度上分也有兩種：溫和搶占和暴力搶占
從我們要解決的問題來看，這幾個策略都有涉及：
- AON集群中的Aon資源組vs mr資源組：我們的quota是基於min保障和max共享的，一般max會是min的1倍以上，當AON集群中的mr任務所在的quota組資源用得比較超(大於min)時就需要使用組間搶占讓aon組盡快把資源收回來；
- AON資源組內：我們的aon任務分實驗和生產，產生優先級是高於實驗的，因此我們期望達到的效果是生產要跑時實驗能把資源釋放出來給生產用，因此組內也需要開搶占；
- 暴力搶占：當aon需要搶占mr時，由於mr有自動的failover，因此可以直接把資源搶過來；
- 溫和搶占：從人性化和高效率的角度，這個才是正道，他的主要思想就是基於一個搶占協議和搶占消息，讓任務的instance能夠感知在X秒內將被強製終止，它可以根據自身情況選擇跑完還是保存現場或者立即終止，這個事的難點是讓mr/ps/xlib等計算框架都支持和能處理這些協議和消息。
這一整套要實施下來周期較長，在實施的過程中，我們發現了另外一個更有用的方案：超賣；
【超賣】
搶占有一個不太好的地方就是基於plan資源的，而物理上機器的實際利用率可能不一定高，且由於需要單獨劃Quota也會擠占fuxi給AON任務的plan資源，因此最終我們決定用超賣的方式來斛利用率這個問題。
超賣的基本思想：超賣的quota其min是一個很小值，不占用集群的plan額度，直接給集群設定一個超賣率（如20%），當某台機器的負載超過一定閾值的時候就將超賣的任務直接殺掉；
當然超賣也是可以和全局調度結合起來用，其實我覺得全局調度+超賣+溫和搶占如果能全部支持的話這個場景下的調度策略的問題能解得基本差不多。
1.1.6 一點感想
建設aon集群實際就是在做物理資源的隔離，實際的建設進度不是很快，主要還是還重了（尤其是存儲遷移最費事），我們也在想如果存儲計算分離做得足夠好後，較為輕便的虛擬集群是不是會更高效點，當然需要把相關的自動化配套建設起來才行，否則一大堆人肉工作也是很難受的。
最後感慨一下：係統調度是一個很難十分十美的跨學科工種；
最後更新：2017-06-06 11:31:22