容器雲資源資料關聯與資料聯動的難點和解決思路
隨著容器雲覆蓋的業務越來越多,日常人工的容器雲維護方式和管理已經無法滿足技術上的需要,因此擁有自動化運維解決方案至關重要。容器雲自動化運維需要覆蓋多種型別的IT環境,並具備可擴充套件的能力,便於獲得對全域性基礎架構的完全可見性和效能控制。實現容器雲自動化運維的核心痛點包括:受限於傳統運維思維,導致自動化能力不強;自動化平臺的經驗沉澱缺乏;開源工具過多,開源選型以及開源治理方法選擇困難。
雲原生應用創新實踐聯盟透過課題方向專家組在“容器雲自動化運維方向”的課題研究,重點圍繞構建容器雲自動化運維體系、容器雲監控體系的分層以及實現方式、容器雲運維與企業運維流程對接融合三方面為企業提供決策參考。幫助企業運維人員提升對容器雲的理解、升級運維思維,為運維人員提供容器雲自動化運維建設的方法建議。
本期介紹容器雲自動化運維方向課題組階段性研究成果“容器雲資源資料關聯和資料聯動的難點和解決思路”。
容器雲資源資料關聯與資料聯動的難點和解決思路
【導讀】
本文探討了基於容器雲場景下資源資料的管理,指出了傳統架構與雲原生架構下資料管理的區別。文中定義了資料資源的範圍,並展開論述了對資料進行管理後的運維獲益場景。企業在雲原生改造過程中,往往會面臨動態資源感知問題,作者也給出了一些切實而有效的解決方向。
前言
在雲原生的背景下,運維體系的構建和能力面臨了很大的挑戰,在傳統的運維場景中,有固定的資源管理方式和流程支撐,同樣,運維對於業務的支撐也無法進行大面積的覆蓋。在雲原生或DevOps的場景中,運維工程師或雲原生工程師需要對運維場景的能力進行升級,比較典型的有,需要具備服務全鏈路質量監控覆蓋,涵蓋資料域與業務域;需要具備智慧化的、集約化的資源動態排程和伸縮機制;需要具備面向終態的監控體系,解決故障預警和問題定位的能力;需要在“價值”交付過程中的各個階段,具備能夠防禦不可靠因素的能力;需要具備資源高效交付的流程機制與快速上線的能力;需要在IT組織內部推進業務快速上雲的能力。
我們可以發現,在以上的所有能力中,有一個核心的要素,資料需要在雲原生的各場景或各能力中,處於中樞地位,需要對資源進行統籌和管理,實現資料之間的關聯和聯動。
一、資源資料的管理方式
1、傳統的資源管理方式
容器雲資源資料的管理和傳統的CMDB有本質的區別,在很多人的理解中,傳統的CMDB僅僅是一個管理IT裝置配置的資料庫,其功能侷限於採集裝置配置和儲存裝置配置,進行配置資料的粗加工,如配置報表和成本報表,如下圖所示。
2、面向自動化運維的資源管理方式
隨著自動化運維理念的普及,以及運維技術的發展,資源管理的方式或方法也悄然“升級”,主要有兩個方面,分別是資料中心的資源管理和應用的資源管理,前者在IT資產管理的功能進行擴充,後者為了更好的為應用資料進行支撐,這兩個方面的核心功能在本質上而言,都是自動化運維推進或落地的重要步驟,如下圖所示,透過問題診斷、資源批次管理、自動巡檢、SLA保障和資源利用率管理的方式提升運維的效率,透過資料自動採集、開放API、視覺化檢視、資源標準化、服務管理的方式為運維自動化提供支撐。
在面向自動化運維的場景中,資源管理是底層的管理能力,透過API能力為上層的應用提供支撐,比較典型的有標準的一致性資料支撐和固化的無障礙流程支撐。
3、面向DevOps的資源管理方式
面向DevOps的資源管理,其實是DevOps和CMDB二者的整合,作者的《DevOps權威指南》中有詳細的描述,在此進行提煉。
CMDB和DevOps的整合場景主要包括業務場景、架構場景、部署場景、資料輸出場景和傳統的基礎架構場景。在業務場景方面,基於業務訪問流的方式,對服務進行視覺化呈現;在架構場景方面,基於架構檢視,對應用的顆粒度進行整合,形成完整的業務和業務的全景檢視;在部署場景方面,包含應用對應的節點和元件,形成應用的部署檢視;在資料輸出場景方面,包括 CMDB 提供的資料所有的對外輸出場景,該場景主要與其他整合場景進行單向和雙向的資料互動;傳統的基礎架構場景是指對底層的基礎設施進行檢視輸出,並提供採集、查詢、儲存和展示功能。
在應用方面, CMDB輔助業務場景,透過DevOps驅動業務流程。在價值交付流水線中, CMDB為各業務流程提供準確的配置資料。業務系統在架構設計、容量管理、持續交付和業務域保障過程中,透過資料賦能,進行業務流程的落地。同時,CMDB 提供的資料的高階使用方式主要是多場景的資料關聯和透過端到端的檢視輔助DevOps在監控領域進行根因分析、故障定位和快速“自愈”。在DevOps的度量和反饋環節,對CMDB提供的資料進行服務化運營,實現業務的運營分析和成本覆盤,以及資源的容量規劃和管理。
二、容器雲資源的管理方式
無論是私有云、公有云,還是容器雲的場景中,都將面臨雲原生的資源管理方式,也叫雲原生資產管理,包括了應用、資料、元件。雲原生的資源管理方式和傳統的資源方式存在很大的不同,在雲原生的環境中,所有的資源都是不停的在變化,因此支撐的應用和場景也是複雜多變的,同時雲原生的應用大都採用微服務的方式,因此管理的配置項數量也呈現幾何級的增加。
在這種情況下,容器雲資源的管理方式需要透過資源資料管理和資源場景管理相結合的方式,透過資源資料定義資源管理的模型、屬性、組合關係,透過資源場景的方式對資源進行描述並對資料型別進行標準化。常見的容器雲資源管理場景如下圖所示。
應用資源管理,包括應用的拓撲資訊,應用的基本資訊如程式包目錄、啟停指令碼等,應用的部署資訊如叢集、環境、主機、程式等,以及應用與應用之間、應用與基礎資源之間的呼叫資訊等。
基礎資源管理,應用是由各種基礎資源構成的,需要支援各種基礎資源的配置資訊管理。
應用製品管理,一般而言,資源管理中不會納管制品,但需要支援與外部製品庫對接,對製品與應用之間的關係進行管理。
作者舉一個典型的例子,便於讀者理解。在容器雲資源管理過程中,需要定義一個資源管理模型,這個模型代表著一類雲資源,如計算資源、儲存資源、網路資源,也包括了叢集模型和製品型別。模型需要以屬性的方式從各個方面雲資源,模型的屬性可以根據場景自由定義和擴充套件。如叢集模型的屬性中,包括叢集名、叢集方式等,主機模型的屬性包括ip、型別、區域等。和傳統資源管理方式最大的不同,隨著業務不斷髮展變化,叢集和主機的資訊也需要進行不斷的擴充套件。
三、容器雲資源資料的關聯
資源資料的關聯,涉及了三個核心問題,分別是如何對資源進行抽象和定義,如何確定資源資料之間的關係,如何在容器雲場景中對資源進行鏈路追蹤。
容器雲資源資料中,包括了容器雲平臺自身的資料,資料中心資料,還包括了面向可靠性保障的事件資料和變更資料,同時也包括面向業務連續性的監控資料、應用配置資料和業務叢集資料。作者在此重點分析聚焦在運維領域的資料,如下圖所示,我們可以清晰的看到,機房、機櫃、伺服器裝置、網路裝置、儲存裝置之間的關聯關係,也可以看到應用、實體、資料庫、系統之間的關聯,這是一種典型的以IP地址為基礎的資料關聯方式。
在上述的容器雲資源資料關聯的場景中,我們可以明顯的看到,應用、資料庫、負載均衡,這三個模型的關聯是雙向的,而物理裝置、網路裝置和儲存裝置的資料關聯是單向的,這是容器的特性所造成。如果將任何一個例項進行模型化展示,PaaS層模型之上會關聯另一個模型,每個模型都有一個屬性資料供其他模型進行使用,從而衍生出一個龐大的資料關聯圖。因此只要任何一個屬性資料發生了變化,相關的資料關聯都會發生變化,甚至會引發資料聯動的情況。
作者同樣舉一個簡單的例子來描述容器雲資源的資料關聯,當運維團隊對某個物件進行監控時,收到一個監控指標的預警資訊,運維負責人首先關注是否影響業務連續性或可持續提供服務的能力是否受到影響,具體負責這個物件的工程師需要在短時間內對這個物件的上下游關係進行故障排查,如這個物件的故障是否因下游元件造成,是否對上游系統造成問題,這個物件在應用服務中處在什麼環境,是否具備高可用能力,所承載的應用屬於那個團隊,近期是否有變更,是否和其他元件存在依賴關係,是否因為容器雲平臺自身的原因造成。在這個時候,就需要一套完整的容器雲資源資料關聯的拓撲圖譜,如應用拓撲、叢集拓撲、模組拓撲、容器雲資源拓撲、資料關聯關係。
資源資料的關聯,不僅僅需要容器雲平臺自身具備資料關聯的能力,還需要和第三方系統進行對接,如介面系統、應用監控系統、配置中心繫統、組織架構系統、運維流程系統,雙邊系統在對接過程中,任意兩個模型都需要透過資料關聯的方式,形成單向或多向的關係。
四、容器雲資源資料的聯動
當容器雲資源資料具備了資料關聯的能力,便需要和具體的場景進行適配,進行資料聯動。通常,在容器雲環境下,運維團隊面臨了各類環境和資源的操作,雖然容器雲平臺具備自身資源資料的聯動,和應用的聯動依然不友好。因此,需要在容器雲平臺內部的資源編排能力之上,透過開發、封裝可編排的元件和外掛的方式,將資源資料以資料聯動的方式提供靈活、可定製、可管理的模板化運維能力,覆蓋面向業務連續性管理過程中的運維管理、運維審批、運維決策和運維執行的場景,最終實現運維自動化和運維智慧化。
可以將容器雲資源資料聯動分為三層,分別為基礎設施層、容器服務層、應用層,其中基礎設施層對應了雲資源聯動,容器服務層對應了kubernetes聯動,應用層對應了運維聯動,還可以對應IT組織內部的其他能力子域的聯動,如下圖所示。
雲資源聯動,聯動物件是各類雲資源,包括計算資源、網路資源和儲存資源,主要透過容器雲平臺內部的編排功能,達到基礎資源彈性伸縮的能力。kubernetes聯動,聯動物件是kubernetes叢集資源資料,主要透過Helm或YAML進行編排。運維聯動,主要面向運維保障、運維監控和運維流程場景,達到自動化運維或智慧化運維的能力。
通常,資源資料聯動在運維場景內主要有四種方式,分別是運維事件的管理、應用呼叫管理、服務部署管理和變更影響管理。事件管理方面,可以透過容器雲平臺和事件系統進行對接,可以對告警進行分析,達到事件資料和釋出資料之間的聯動。應用呼叫管理方面,可以透過容器雲平臺和應用鏈路系統進行對接,對故障應用的上下游呼叫鏈路進行分析,匹配服務異常原因和應用鏈路呼叫之間的影響關係。服務部署管理方面,可以透過容器雲平臺自身的資料進行關聯分析,及時的辨識變更和告警之間關係。變更影響管理方面,可以透過容器雲平臺和變更系統進行對接,打通業務連續性各項指標之間的關聯,透過資料聯動的方式明確變更可能發生影響的範圍。
執筆專家
顧黃亮 容器雲自動化運維使用者委員會委員
twt社群雲原生應用創新實踐聯盟——容器雲自動化運維方向課題組組長。中國商聯智庫入庫專家,企業數字化轉型IOMM委員會特聘評估專家,騰訊雲最具價值專家TVP,阿里雲最有價值專家MVP,《企業級DevOps權威指南》作者,《研發運營一體化(DEVOPS)能力成熟度模型》核心作者,《企業IT運維發展白皮書(2019)》核心作者,2020容器雲技能大賽課程出品人,多個技術峰會分享嘉賓。擁有豐富的企業級DevOps實戰經驗,專注企業IT數字化的轉型和落地,致力於企業智慧運維體系的打造。
顧問專家
曹伍 容器雲自動化運維使用者委員會委員
twt社群雲原生應用創新實踐聯盟——容器雲自動化運維方向課題組專家。現就職於光大科技,從事軟體架構開發工作,熟悉雲原生,微服務等技術領域。參與過雲平臺設計、開發、運維工作,提供過應用上雲技術諮詢服務。
毛天明 容器雲自動化運維使用者委員會委員
twt社群雲原生應用創新實踐聯盟—— 容器雲自動化運維方向課題組專家。5年大型保險公司容器雲建設與推廣經驗,覆蓋伺服器規模超萬臺。工作主要從事devops流程設計、雲原生架構建設、應用容器化改造。2020 容器雲職業技能大賽百位專家委員會成員。
來自 “ twt社群 ”, 原文作者:twt社群;原文連結:https://mp.weixin.qq.com/s/0Xf1S0FpVKF3Dn17wYshHQ,如有侵權,請聯絡管理員刪除。
相關文章
- 資料結構——關聯容器資料結構
- crane:字典項與關聯資料處理的新思路
- 關聯式資料庫與文件資料庫對比資料庫
- config表與其他資料表的關聯
- SQLAIchemy資料模型關聯SQLAI模型
- 如獲取獲取關聯資料的文件跟模型的關聯資料集呢模型
- 關聯資料的釋出與視覺化視覺化
- Oracle資料不同步的問題分析和解決思路Oracle
- oracle資料庫常見故障和解決難度Oracle資料庫
- springboot建立與資料庫關聯模組Spring Boot資料庫
- Oracle資料庫遷移到國產資料庫核心難點解析 | 聯盟釋出Oracle資料庫
- 關聯式資料庫很快會替代向量資料庫資料庫
- 更新關聯資料初始化
- Web Sql 關聯式資料庫WebSQL資料庫
- RAG場景、資料、應用難點與解決
- 圖解主資料的單源與多源以及集中與聯邦管理圖解
- 多資料來源與動態資料來源的權衡
- 後端開發中關聯式資料庫的開發管理新思路後端資料庫
- GeminiDB全面聯動MySQL:熱點資料,一鍵加速MySql
- Recoil 中多級資料聯動及資料重置的合理做法
- 如何將傳統關聯式資料庫的資料匯入Hadoop?資料庫Hadoop
- 工業物聯網解決方案:PLC資料上雲
- 關聯式資料庫 Query_Execution資料庫
- hyperf關聯子表查詢主表資料
- sql 多表關聯刪除表資料SQL
- Redis全文搜尋教程之建立索引並關聯源資料Redis索引
- 關聯式資料庫的正規化(Normal Form)知識點資料庫ORM
- 認識物聯網系列—物聯網與雲端計算、大資料大資料
- 資料湖+資料中臺,金山雲大資料平臺如何攻克資料價值落地難關大資料
- Springboot專案啟動後自動建立多表關聯的資料庫與表的方案Spring Boot資料庫
- 資料倉儲、資料湖與湖倉一體的區別與聯絡
- 物聯網的資料方案
- 混合異構資料來源關聯計算最佳化方案
- 事件溯源超越關聯式資料庫 - confluent事件資料庫
- MybatisPlus多資料來源及事務解決思路MyBatis
- 硬碟資料丟失原因和解決方案/資料恢復方法硬碟資料恢復
- C/C++ Qt 資料庫與ComBox多級聯動C++QT資料庫
- C/C++ Qt 資料庫與TableView多元件聯動C++QT資料庫View元件