- 一、背景
- 二、概述
- 三、下線流程與原理
- 1.讀取待下線節點串列
- 2.判斷節點下線模式
- 3.設定超時時間
- 4.RMNode 處理下線事件
- 5.監控節點的狀態、下線節點
- 四、相關的Yarn集群配置
一、背景
接手部門 Hadoop 和 Flink 集群半年了，一直忙著上云的事兒，很少有時間去琢磨運維的事兒，上完云之后，老板著重強調要穩定，尤其是 Flink 集群，穩定性是實時任務最重要的指標，因為我們是 Flink on Yarn 的模式，Yarn 的節點上線和下線其實就是兩行命令的事兒，但是 Flink 集群就不能這么做了，
我們的機器配置比較高，一臺機器上可能跑著上百個 Flink 任務的 Taskmanager 或 JobManager，直接把 NodeManager 節點摘掉，影響的任務太多，風險就比較大，所以老板讓我調研一下如何把下線節點做到對業務方的影響無感，把風險降到最低，
在查閱了一番的資料之后，找到了相對好一點的辦法：先把機器從 Yarn 上 Graceful Decommisson，然后逐個 kill 這臺機器上任務的 task，這種做法的好處在于：第一，下線期間，不會有新的 Container 分配到這臺機器上；第二，逐個 kill 讓風險可控，有一個 Buffer，
二、概述
??Yarn 集群的擴容非常簡單，只需要在新的機器節點上，運行 NodeManager 服務，Yarn 會自動完成節點注冊，資源檢測等操作，然后在該節點上運行任務，除了易于擴容，Yarn 還支持通過下線 (Decommission）節點的方式實作彈性縮容，Yarn節點有兩種下線方式：
??一個是正常的 DECOMMISSIOIN 方式，直接在節點上關閉 NodeManager 服務，這種方式會導致運行在該節點上的所有 container 全部 failover，
??另一種更優雅的方式 GRACEFUL_DECOMMISSION，不會直接關閉 NodeManager 服務，而是會盡可能地降低對運行中的任務的影響，節點處于下線流程期間，ResourceManager 不會向這些節點調度新的 container，并等待正在運行的 container 都結束（或者達到指定的超時時間），才會將節點標記為 Decommission 狀態，將其從集群中洗掉，
三、下線流程與原理
#節點下線命令
yarn rmadmin -refreshNodes [-g [timeout in seconds] -client|server]
1.讀取待下線節點串列
??首先需要在集群組態檔中指定需要下線的節點串列，如果每個節點下線的超時時間不同，還需要額外對每個節點配置單獨的超時時間，然后使用上述節點下線命令，
??使用上述命令后，ResourceManager 中的 NodeListManager 組件會讀取待下線節點串列檔案（目前該檔案只支持文本或者xml格式），具體來說，如果想要實作每個節點單獨配置下線超時時間，那么該檔案必須是 xml 格式，
2.判斷節點下線模式
??讀取到需要下線的所有節點Host之后，Yarn 會按照命令中指定的模式處理下線：client 或 server 模式，
??這兩種模式的區別在于，超時時間配置生效的優先級和超時時間處理的物件，
- 在 server 模式下，優先級是 待下線串列檔案 > 下線命令 > yarn配置；在 client 模式下，只有下線命令中指定的超時時間會生效，
- 在 client 模式下， client 會處于阻塞狀態來追蹤是否達到超時時間；而 server 模式下，該作業由 ResourceManager 完成，
3.設定超時時間
??讀取到有效的超時時間后，NodeListManager 會給每個 RMNode 設定單獨的超時時間，這個超時時間也可以通過再次使用上述命令的方式進行動態調整，重復使用上述命令并不會重置超時時間，只會影響節點是否超時的判斷，
??比如說，在 1:00 設定了某個節點2小時后（即3:00）下線，如果在 2:00 的時候，再次使用該命令設定該節點的超時時間為3小時，那么此時該節點的下線時間會是 4:00 而不是 5:00，過去的這1個小時的時間并不會被重置，如果這個時候再將超時時間設定為1小時，下線時間就會是2:00，那么該節點將立即下線，
4.RMNode 處理下線事件
??在收到 GRACEFUL_DECOMMISSION 指令后，RMNode 會保存指定的超時時間，并更新節點指標，保留其總的資源容量資訊，并切換到待下線（DECOMMISSIONING）狀態，處于該狀態的 RMNode 會定期動態地更新資源情況，防止因為集群可用資源不足，scheduler 將新的 container 分配到將下線節點上，
5.監控節點的狀態、下線節點
??在收到 GRACEFUL_DECOMMISSION 指令后，Yarn 會啟動一個組件 DecommissioningNodeWatcher 來自動地異步監控待下線（DECOMMISSIONING）節點的狀態，待下線節點的 NodeManager 行程會定期發送心跳，來報告其上所有運行的 container 的最新運行狀態，DecommissioningNodeWatcher 會監控這些 container 的狀態，并在所有的 container 運行完成后，通知 NodeManager 關閉，并將該節點切換為已下線（DECOMMISSIONED）狀態，
??由于在 MapReduce 任務中，即使一個節點上所有的 container 都運行完了，它仍然會為 reducer 提供 map 的輸出資料，在這種情況下，Yarn 的 GRACEFUL_DECOMMISSION 機制會保留這些待下線節點（即使該節點上所有 container 都運行完了），直到所有涉及的任務都運行結束，
??但是某些任務可能會長時間運行，這就會導致待下線節點上的 container 一直無法運行完成，或者即使運行完了也需要讀取資料而無法下線節點，而超時時間的作用就是，只要達到超時時間，不管 container 或者任務有沒有運行完成，DecommissioningNodeWatcher 都會將節點下線，沒有完成的任務會 failover，
??所有待下線節點的狀態，都會定期（默認每20s）記錄在 ResourceManager 的日志中，以下是待下線節點的所有狀態：
??NONE ?????? – ?? Node狀態正常，并不是待下線節點
??WAIT_CONTAINER ?? – ?? 等待所有 container 運行完成
??WAIT_APP ??? – ?? 等待所有涉及的 application 運行完成（在所有container完成后）
??TIMEOUT ????? – ?? 超時
??READY ????? – ?? 準備下線
??DECOMMISSIONED ?? – ?? 已下線
四、相關的Yarn集群配置
yarn.resourcemanager.nodes.exclude-path
需要下線的節點 Host 檔案路徑，
yarn.resourcemanager.nodemanager-graceful-decommission-timeout-secs
GRACEFUL_DECOMMISSION 下線節點的超時時間，默認值為 3600s，即1小時，
如果將該值設為負數，則節點會等到所有任務完成，永遠不會強制下線節點，視具體情況，可以在執行下線命令前修改該值，或者直接通過命令指定，
yarn.resourcemanager.decommissioning-nodes-watcher.poll-interval-secs
DecommissioningNodesWatcher 內的輪詢計時器任務的周期（以秒為單位），用于識別和處理心跳資訊缺失的待下線節點，默認值為 20s， 私有云使用默認值，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/542647.html
標籤：大數據