Hadoop新特性、改進、優化和Bug分析系列2：YARN-45

背景介紹

在2.1.0-beta之前，ResourceManager本身沒有提供直接的資源搶占RPC接口，也就是說，從語義上講，YARN是不支持資源搶占的。然而，Hadoop最著名的調度器（參考我的這篇文章：Hadoop調度器總結）之一Fair Scheduler（參考我的這篇文章：Hadoop 0.21.0中公平調度器實現）最大特色之一是支持資源搶占，它當然不想拋棄這個功能變得跟Capacity Scheduler（參考我的這篇文章：Hadoop容量調度器介紹）一樣平庸，由于它就拐彎抹角的實現了資源搶占，它是怎么實現的呢，方法很簡單也很粗魯：當需要為某個“更重要”的應用程序分配資源而資源不夠用時，需要搶占別的應用程序占用的資源來“拆東墻補西墻”，采用的策略非常野蠻，在事先不告訴應用程序主管（指ApplicationMaster）的情況下，強制殺死它的弟兄（任務），很顯然，各個應用程序主管會非常的不滿，這也有損YARN資源管理的形象，隨著Hadoop生態系統的完善，當然不希望這種不和諧的場面出現，于是更友好地資源搶占策略提上了日程。

在正式介紹YARN資源搶占策略之前，我先介紹一下為什么需要有資源搶占策略，這種策略用在哪些場景下?我們都知道，YARN作為一個資源管理系統，最重要的工作是管理集群中的所有資源，并按照應用程序各種資源要求將滿足要求的資源分配給他們，比如有些應用程序優先級高，更重要，有資源要先給它；有些應用程序需要跑一個服務（Service），想要質量高一點的資源；有些應用程序跑的任務是一個“團伙”，需要資源全部到位后才會一起運行等，YARN作為一個“服務商”，要盡量滿足各種形形色色的客戶要求，而為了提供更優質的服務，讓客戶整體滿意度更高，搶占機制是必須的。總結起來，搶占機制通常用于以下幾種場景：

（1）重分布各應用程序的資源量和公平資源量。比如，當集群資源動蕩時，調度器需要時不時的調整各個隊列資源分布情況，以保證盡可能公平公正地分配資源。

（2）殺死特定的container。這種場景也很多，比如殺死一個正在運行的任務將其遷移到另外一個更優質的節點（比如locality更高，CPU性能更好等）上運行，殺死一個運行在存在IO瓶頸節點上的任務（比如Shuffle熱點節點），并將其遷移到一個IO環境良好的節點上運行（注意，YARN 只對CPU和內存資源進行了隔離，其他資源比如網絡和磁盤IO沒有隔離，仍可能產生瓶頸哦，這個短時間內搞不定，需要看cgroup的進展）。

（3）管理員對集群中個別節點進行維護。為了對一批機器進行維護，通常先要“友好的”殺死這些節點上的任務，以讓他們進行一些“善后”處理工作，比如對一些service任務，可以做一些checkpoint以便下次恢復運行現場。

講到這里，我需要再提醒一下各位讀者，YARN的定位是一個通用的資源管理系統，類似于一個云操作系統，可以管理一個集群或者數據中心中的各種資源，它不僅僅用來跑MapReduce這樣的應用，可也以跑MPI、Storm、Spark這樣的計算框架，當然，更可以跑Service，比如一個mysql實例、一個Web Server等，只不過是，由于YARN處于發展初級階段，很多地方尚不完善。

解決方案

為了更友好的支持資源搶占，YARN提出了新方案，具體如下：當需要搶占某個應用程序的資源時， ResourceManager先將待搶占的資源發送給應用程序的ApplicationMaster，讓它自行了斷對應的任務，比如做一些checkpoint以幫助下次運行時恢復現場等（然后再殺死對應的任務），如果在一定時間內，ApplicationMaster“無視”老大（即ResourceManager）的命令，則ResourceManager再進一步強制干掉這些任務。需要注意的是，集群的資源量變化是動態的，不同時刻，總的資源量，正在使用的資源量等信息是變化的，ResourceManager要求ApplicationMaster強制釋放的資源可能在下一刻已經自行得到了釋放，這種情況下，是沒必要強制殺死任務的。

對于前面提到的場景，我們可以概括為，在（1）（3）兩種場景中，ResourceManager向ApplicationMaster發送一個總的資源量即可，具體殺死哪些任務湊齊這些資源，完全由ApplicationMaster自己決定，比如它可以選擇一些剛剛啟動的任務（這樣代價最小）；第（2）中場景中，ResourceManager必須顯式指明要殺死的Container列表，ApplicationMaster收到該列表后，嚴格執行命令依次殺死這些Container中運行的任務。

讀者可能已經注意到，這個Hadoop jira鏈接很長，幾個主要人物進行了反復的技術討論，線上討論，線下討論……，方案也是在不同變化，一會變成“ResourceManager只發送總的資源量，以便將更多的權利下放給ApplicationMaster”，一會變成“ResourceManager發送需釋放的Container列表，以彰顯ResourceManager絕對的控制權力”，最終，當YARN項目的老大Arun C Murthy假期歸來之后，一拍版定為最初的方案，也就是兼顧三種場景的方案，具體如下：

在心跳信息，即ResourceManager應答給ApplicationMaster的信息AllocateResponse中（即RPC函數AMRMProtocol#allocate()的返回值，注意從2.1.0-beta開始，AMRMProtocol協議被改名為ApplicationMasterProtocol）增加PreemptionMessage消息，對應ProtocolBuffers的定義如下：

message PreemptionMessageProto {

optional StrictPreemptionContractProto strictContract = 1;

optional PreemptionContractProto contract = 2;

}

message StrictPreemptionContractProto {

repeated PreemptionContainerProto container = 1;

}

message PreemptionContractProto {

repeated PreemptionResourceRequestProto resource = 1;

repeated PreemptionContainerProto container = 2;

}

message PreemptionContainerProto {

optional ContainerIdProto id = 1;

}

message PreemptionResourceRequestProto {

optional ResourceRequestProto resource = 1;

}

在PreemptionMessageProto定義中，StrictPreemptionContractProto是必須釋放的container列表（不可忽略，若忽略，ResourceManager強制干掉這些container），PreemptionContractProto則給出資源總量和建議釋放的container列表， ApplicationMaster可自己選擇釋放哪些container以湊集總資源量，這樣給ApplicationMaster留下了發揮空間，可做的更加智能些。當然，ApplicationMaster收到這些信息后，可自行決定是否殺死對應的container，它可以選擇忽略，由ResourceManager強制殺死它們，需要注意的是，集群資源狀態時動態變化的，ApplicationMaster使用的資源在不斷的釋放中，ResourceManager此刻要求釋放的container，下一刻可能就不要求了。

在這個jira鏈接中，ResouceManager和ApplicationMaster之間的協議進行了修改，這就要求各個調度器均要充分利用這個修改增加更加先進的搶占機制，同時已有的ApplicationMaster也要修改對應代碼以便能夠理解這種消息的語義，接下來各個模塊的負責人都有活干了，這也進一步說明了，通信架構最好不要動，一旦動了，就會產生無數的工作量。由于該jira的修改產生的相關鏈接如下：

（1）CapacityScheduler: support for preemption (using a capacity monitor)：

https://issues.apache.org/jira/browse/YARN-569

（2）RM changes to support preemption for FairScheduler and CapacityScheduler：

https://issues.apache.org/jira/browse/YARN-567

（3）FairScheduler: support for work-preserving preemption：

https://issues.apache.org/jira/browse/YARN-568

（4）User guide for preemption：

https://issues.apache.org/jira/browse/YARN-650

（5）Basic AM changes to support preemption requests (per YARN-45)：

https://issues.apache.org/jira/browse/MAPREDUCE-5189

當然，在YARN發展初期，這種改動是正常的，畢竟YARN這種系統本身就是從無數應用中抽象出來的，他總伴隨應用種類的增加而不斷的發展與前進。

我們學到了什么

涉及到系統底層通信語義的修改，一定要反復磋商，對于YARN而言，一定要清楚各個組件的定位和職責，不可賦予一個組件它不應該具備的職責，這樣下去，所有組件的職責會變得過于交叉錯亂，失去了架構的簡潔性。

原創文章，轉載請注明： 轉載自董的博客

本文鏈接地址: http://dongxicheng.org/mapreduce-nextgen/hadoop-jira-yarn-45/

作者：Dong，作者介紹：http://dongxicheng.org/about/

本博客的文章集合:http://dongxicheng.org/recommend/

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com