《04-美團大數據及機器學習基礎設施云原生改造實踐-吳通.pdf》由會員分享,可在線閱讀,更多相關《04-美團大數據及機器學習基礎設施云原生改造實踐-吳通.pdf(54頁珍藏版)》請在三個皮匠報告上搜索。
1、美團數據及機器學習集群云原改造實踐 美團數據平臺資源與系統負責/吳通錄早期架構及升級背景 云原改造過程 關鍵問題和思考 未來規劃改造前架構場景特點數據和機器學習兩個場景,先有數據,后有機器學習 數據場景供需共構,對擴展性、可觀測性等訴求不,機器故障率低 機器學習場景供需異構,對調度語義、擴展性、可觀測性、運維友好均有訴求,機器故障率改造前痛點擴展App類型復雜度 依賴AM,戶感知,影響資源統計 持GPU、RDMA、NPU等設備復雜度 調度策略定制成本 故障感知、監控、可觀測平低更深層次的原因離線場景的路徑依賴 架構變更帶來的不確定性 K8S VS YARNYARN:分布式集群資源調度系統 K8
2、S:分布式集群操作系統,管理集群資源的,不僅僅是調度改造后架構錄早期架構及升級背景 云原改造過程 關鍵問題和思考 未來規劃控制改造內容概覽組件改造內容簡介etcd服務器和客戶端均升級3.5.5,提升性能并修復單節點revision落后較多的問題kube-apiserver1.解決負載不均衡問題2.httplog獲取userAgent可能觸發map并發讀寫問題3.修復get&watch在apiserver_request_duration_seconds_bucket錯誤展示的問題controller-manager1.改造Endpoint Controller,以解決underlay CNI不
3、持ClusterIP service問題2.增強NodeLifecycle Controller處理Not Ready Node的能,降低節點不可對已有負載的影響Operator1.SparkOperator:解決spark on k8s,持spark 2.2和RSS2.TrainingOperator:解決TF、MPI、PyTorch on K8S,持容錯3.AFOServingOperator:以PaaS式解決TF、PyTorch、Triton 推理 on K8S4.OrdinaryServingOperator:以類IaaS式管理在線服務5.Codelab Operator:以容器式給程
4、師提供開發實驗環境 6.PrestoOperator:Presto cluster on K8S,持彈性容錯調度器研調度器,持各種級特性,吞吐平較節點端改造內容概覽組件改造內容簡介物理機調整掛盤式,借助硬/軟Raid解決kubelet不能管理多磁盤的問題kubelet1.卡、GPU親和性持到PCIE級別2.持多卡Pod分配多IP3.不同作業采不同的oom處理策略4.改造static cpu manager,適配預留cpu核的綁核法5.修復系列導致kubelet不穩定的問題,如device權限、terminating pod、IP回收等問題device plugin1.gpu-device-pl
5、ugin持按卡類型匯報資源名2.gpu-device-plugin、rdma-device-plugin持更豐富的設備健康檢查和異常處理機制3.gpu-device-plugin、rdma-device-plugin持PCIE級親和策略4.npu-device-plugin持ring內npd1.增強節點異常檢查功能,保證節點在運期環境是符合預期的2.包括CPU、GPU、卡等硬件環境,也包括存儲系統、IP管理等軟件環境絡1.采underlay CNI,實現pod和集群外部絡資源互聯2.改造clusterIP service實現式,實現在underlay CNI的負載均衡案存儲1.持訪問HDFS,
6、主要解決從NameNode獲取token和renew token,并存儲到Pod內的問題2.持訪問Dolphin FS,實現了套CSI Driver,采靜態提供PV的式,并持件系統故障后可動恢復,不影響已有負載 3.持訪問EBS,實現了套CSI Driver,采動態提供PV的式。來剝離解決實驗開發場景的狀態保存,以實現掛起恢復功能改造內容概覽組件改造內容簡介監控告警1.3分2副本Prometheus,3thanos,3thanos-ruler2.建設k8s_alert對接公司內部的告警系統3.建設raptor-adaptor,對接在線服務指標到公司內部中間件可觀測1.主流志案般采消息隊列實時收
7、集志,但解決不了時延、時序和丟失問題,對戶troubleshooting影響很 2.研了套志案,基本思路是在每個節點部署簡單的件服務器來讀取running狀態pod志,pod結束后持久化到s33.構建了套數據收集案,實時收集etcd和Prometheus等數據源的數據,并通過消息隊列存儲到持久化存儲4.構建了數百張dashboard,描述系統的運狀況和不同組件的內部細節,并借此指導各類優化作研調度器簡介持多租戶配額管理,持排隊 集群唯調度器,持Gang Scheduling,租戶間、租戶內公平調度 持搶占式調度,配額之上增加彈性量,提升資源利率 持劃分邏輯資源池,Pod適應優選策略,減少GPU
8、碎 持RDMA親和性調度,更好地撐性能計算需求 完善的退避機制,持租戶-Job-Pod多層級退避 調度吞吐300+pods/s租戶-配額管理兩級隊列:隊列:租戶,隊列:租戶內細分,min:配額,max-min:彈性量 Pod劃分:System Pod,User Pod(指定PodGroup),單調度器統調度 Gang Job:PodGroup唯映射個Gang Job,指定作業提交隊列主流程OpenSession:從cache中復制Node、Queue、Job和Pod等對象,使調度流程鎖化 AllcoateSystem:調度System Pod,優選過程,快速調度 PreAllocate:為上輪
9、搶占成功的User Pod分配節點,Gang Job遵循事務提交 Allocate:調度User Pod,搜索最優Node,Gang Job遵循事務提交,核流程 Preempt:為調度失敗的User Pod搶占資源,Gang Job遵循事務提交,核流程 CloseSession:更新Job和Pod狀態,記錄event事件和監控指標數據 調度概述隊列公平調度:配額滿率低的隊列優先 Gang Scheduling優先調度:未滿Gang的Job優先 Job公平調度:Pod調度率低的Job優先,防個Job餓死其他Job 優先級調度:持隊列內指定Job優先級、Job內指定Pod優先級 異構調度:持10+
10、種GPU卡型,持5+種命周期、特點不的任務 調度語義豐富:持k8s原調度語義,擴展了如適應聚集/均衡調度、RDMA絡親和調度等搶占概述隊列max min即表示開啟彈性調度,max-min部分的資源占在集群資源緊張時會被搶占 隊列只在配額未滿的情況下才能搶占,彈性量部分不通過搶占來滿 公平性:和調度過程類似,優先為配額滿率低的隊列和Pod調度率低的Job發起搶占 優先級搶占:持隊列內指定Job優先級、Job內指定Pod優先級,搶低優保優 Gang Scheduling保護:優先搶占每個Job超出minMember的Pod,如果Gang Scheduling被破壞,則搶占整個Job搶占關鍵實現-G
11、ang Scheduling Gang Scheduling:為Job分配于等于minMember數量的Pod 調度事務化,連續為Job調度夠數量的Pod后提交調度結果,否則回滾 搶占分成兩步,先嘗試僅搶占超出minMember部分的Pod,再執Gang搶占搶占關鍵實現-兩級事務控制為Gang Job發起搶占會有多個Preemptor,多個Preemptor搶占結果提交需要保證原性;每個Preemptor可能搶占Node上的多個Preemptee,多個Preemptee的搶占結果也需要保證原性。邏輯資源池劃分核思想:刻畫任務類型特征,在資源碎、可性、性能和可維護性之間找到平衡點 有狀態的作業。
12、執遷移和運維動作困難,盡量聚集在批機器上 規模訓練作業。單worker占據整機資源,集群需要預留些空載機器 多實例在線服務。將不同實例打散到不同機器,當節點故障時降低對服務的影響 在邏輯上分成 均衡池 和 聚集池。均衡池負責多實例應的容錯和提升集群整體IO及絡帶寬,聚集池降低尺Pod的等待時間,并將有狀態作業束縛在少量機器上。邏輯資源池只是種優選機制,當聚集池滿了之后,聚集型的Pod也可以被調度到均衡池中,反之亦然。退避機制前提假設:輪調度失敗的任務,在之后輪中概率還是失敗 四級退避設計:指數退避算法,防”壞分”,減少調度器做謂調度,充分保證正常隊列、任務的調度需求,在調度負載場景下可以顯著提
13、升調度吞吐Codelab OperatorCodelab是基于容器實現的實驗開發環境,定位于戶進規模開發實驗,提供隔離獨的開發環境,持久化存儲實驗環境和數據,能快速啟動和恢復 Codelab核功能:1)狀態持久化,持掛起和恢復;2)資源監控;3)集成實驗環境及WebIDE,如JupyterNotebook、PyCharm等 什么是CodelabCodelab系統架構1.Application應層:通過APIService暴露API給戶,渲染Codelab yaml 2.Controller控制層:調諧PC的切為 3.Storage存儲層:Codelab通過PVC掛載或客戶端訪問所需共享存儲Co
14、delab Operator架構準備:前置準備作,如添加Finalizer,申請HDFS訪問token等;創建Pod:根據podTemplate創建Pod及其相關資源 掛起和恢復:通過spec.pause標記掛起和恢復期望,掛起時刪除Pod,恢復時重新創建Pod;同步集群外資源:對接公司內服務樹系統,將Codelab注冊到某個AppKey;刪除和清理:清理效Codelab,從Appkey注銷,并釋放HDFS Token;更新狀態:計算Codelab狀態,并更新.status 通過容器共享掛載實現初始化容器件共享 使EBS存儲持久化戶開發環境,主要包括yum和pip包 使Dolphin FS儲存
15、組內共享的數據和代碼 pc-start.sh作為systemd服務初始化CodelabCodelab啟動過程1.閑時動掛起Codelab,刪除Pod,釋放所占計算資源,保留PV 2.恢復時將重建Pod,重新掛載PV,恢復數據和環境掛起與恢復Dolphin FS接簡介Host Path-CSI 租戶錄唯映射PV,靜態綁定加速調度 多Dolphin FS集群動識別,業務感知 Pod粒度fuse,提升讀寫并發 Fuse進程位于物理機,升級CSI plugin不中斷掛載 持掛載點異常檢測和熱恢復改造前痛點:機器上所有Pod共享同個掛載點,掛載進程異常影響所有Pod 客戶端發重啟,容器內的掛載點丟失,法
16、熱恢復,只能重啟容器 客戶端升級等運維操作會導致掛載中斷,常運維“戰戰兢兢”針對多集群掛載需求,每種上層作業引擎需要重復適配 租戶掛載固定錄,設計個租戶唯映射個PV 預分發租戶PVC和PV,并完成靜態綁定,加速調度過程租戶-PV映射機制多集群動識別 多集群的配置信息存到ConfigMap,并掛載到CSI Pod,持熱更新 CSI通過PV中攜帶的租戶信息定位數據所在Dolphin FS集群,并將對應集群掛載到PodPod Level Fuse 每個Pod都有獨的Fuse進程,即使Fuse進程掛掉,也不影響其他Pod的正常讀寫 Fuse作過程涉及戶態和內核態切換,般對IO的并發有所限制,獨享Fus
17、e在并發IO時具有性能優勢CSI Connector 如在CSI Pod中啟動Fuse進程,container重建導致Fuse進程重啟,穩定性差 借助csi-connector,將Fuse進程代理到物理機,交由systemd來管理,和CSI解耦掛載點檢測和熱恢復 掛載點可以恢復的核關鍵在于:Linux Mount Propagation。CSI雙向傳播掛載kubelet數據錄,錄的掛載/卸載操作會傳播到宿主機 Pod使HostToContainer,可以將宿主機的掛載事件傳播到容器志服務志架構簡介 志收集 志訪問實時收集不可改造成本:對多志缺乏持,改造成本很 收集鏈路的要求:收集鏈路,flue
18、ntbit-log-agent-kafka-es,該架構法解決收集時延、志丟失和失序的問題 離線式能較好解決問題志收集優化志掛載不同pod如何掛載不同錄 通過改造kubelet持如下模式掛載如何感知何時上傳S3 調整kubelet的ttl參數,Pod刪除后保留分鐘容器元數據,輪詢docker接獲取容器信息 兜底:從志路徑還原Pod信息 志訪問優化集群外部署 當節點故障,志服務通過Fail over機制訪問集群外同等接提升訪問成功率 前節點外部署可以避免約0.43%的訪問失敗SEEK接獲取志 S3及本地件均提供seek接,可根據偏移量獲取件內容,提升接效率訓練整體流程作業概覽作業資源監控作業志錄
19、早期架構及升級背景 云原改造過程 關鍵問題和思考 未來規劃規模集群關鍵問題與思考調度能 穩定性 資源效率調度能吞吐量、調度語義的權衡 命周期和是否有狀態對運維的影響穩定性基礎環境的可預期:標準定義、異常發現、異常處理和標準變更 組件穩定性:控制組件和節點組件 資源隔離和QoS:關鍵是場景需要資源效率提升效率的段運維提效,建設動投產、維修系統 異常檢查、動恢復 降低節點級別異常頻率:修復節點端各類問題、隔離系統和業務進程 節點/單卡故障動維修 故障效診斷、維修保有率通過搶占釋放些租戶暫時不使的資源 作業分級,空閑卡跑低優作業 跨集群跨卡型調度機制 混部調度率優化容器啟動速度 全位的作業命周期異常為探測,治理不合理法 MPS、MIG、vGPU等單卡復技術 預測服務彈性伸縮 調度負載率未來規劃完成數據離線和實時場景的云原改造 場景間混部提升資源效率 構建場景適配的調度能 持續提升穩定性和資源效率