民生銀行數據庫智能運維的探索與實踐:DBPaaS數據庫統一管理平臺

01 背景與挑戰

數字化轉型帶來的數據庫運維挑戰越來越大

隨着數字化、互聯網的快速發展,民生銀行正在加快推進全面改革轉型,以“數據+技術”雙輪驅動,着力打造數字化智能銀行。業務創新與技術架構演進需要底層基礎軟件平臺的強有力支撐。

目前我行生產環境運行着數千套數據庫,數據庫種類從成熟的商業數據庫產品逐步轉向開源數據庫、國產數據庫。數據庫運行環境和架構也越來越豐富,從高性能物理服務器加共享存儲轉變爲各種虛擬化甚至容器化環境;從基於共享存儲的雙機互備高可用架構,發展爲雙活數據中心、兩地三中心、讀寫分離、分庫分表等架構方式。數據庫運維的挑戰越來越大。

實現標準化、自動化、集中化、智能化的數據庫運維理念

爲應對數據庫運維挑戰,助力我行數字化轉型,數據庫運維團隊提出了標準化、自動化、集中化、智能化的數據庫運維理念。

DBPaaS數據庫統一管理平臺就是在此背景下開始建設的。整體目標是實現數據庫運維流程、運維規範的標準化,實現數據庫部署上線、擴容、變更、巡檢、回收下線等維護工作的自動化,實現數據庫資源管理、性能管理、容量管理、問題管理等管理功能的集中化、可視化,實現數據庫問題分析,監控預警的智能化。實現數據庫運維從手工模式向工具平臺化、精細化的轉型。

堅持有效整合、自主可控的建設思路

經過多方考察調研,結合實際使用經驗,我們決定遵循有效整合、自主可控的思路進行平臺建設。一方面我們借鑑整合成熟數據庫管理技術框架,與具備豐富數據庫管理平臺建設經驗的外部資源合作,快速搭建基礎平臺,進行項目一期建設投產。另一方面我們堅持自主可控,根據實際的需求和我行現有運維工具體系對實現策略、具體功能以及建設目標進行靈活調整,投入大量的精力在需求分析、架構設計、運維體系規範化以及運維流程建設上,同時深度參與到平臺腳本及源代碼的開發工作中,做到源碼級自主可控。

02 架構和設計理念

微服務架構

DBPaaS數據庫統一管理平臺基於微服務架構,對平臺中的功能進行分層和分模塊設計,明確功能邊界,實現自主可控、開放和可擴展的總體架構。

通過層次化設計,從架構上我們將服務分爲基礎服務,交互服務和集成服務三類,如下圖所示:

圖1-基於微服務架構的開放式和可擴展性設計

基礎服務:基礎服務是整個平臺的基礎,包括監控引擎、自動化運維引擎、CMDB服務、監控數據服務、分析引擎、SQL執行以及任務調度等後臺服務。基礎服務提供平臺基礎功能,通過公共API爲前端功能提供訪問接口;

交互服務:提供平臺用戶直接使用和交互的功能性服務,包括監控告警、問題管理、性能容量、工具箱、報表、操作審計、配置管理以及用戶管理等;

集成服務:提供集成功能服務,將數據庫統一管理平臺作爲數據庫運維的統一入口,並無縫對接我行現有運維管理平臺或工具,例如單點登錄、流程系統、統一告警平臺等。

無縫集成

經過多年的持續建設,我行已經積累了豐富的IT運維工具資產,例如單點登錄系統,統一告警平臺,CMDB系統,移動運維平臺,集中監控平臺,ITOMS流程系統,雲圖系統等等,這些運維工具和平臺經過多年的實際使用和優化,運行穩定,已經融入了運維人員的日常工作當中。數據庫統一管理平臺需要與現有的運維體系無縫集成,例如通過單點登錄實現系統登錄,通過統一告警平臺推送數據庫告警,通過CMDB系統直接納管目標數據庫,集成集中監控平臺採集的主機監控數據,集成ITOMS系統完成運維操作的審批流程等。只有這樣才能確保不形成新的工具類孤島,降低平臺的使用門檻,提高平臺的接納程度。

同時,隨着應用開發模式向DevOPS轉變,以及應用端到端的一體化運維理念,數據庫統一運維平臺需要提供開放的API供其它工具或平臺調用,例如向DevOPS平臺提供數據庫

SQL執行與SQL審覈的接口,向智能運維平臺提供數據庫的監控數據等。

功能可擴展性設計

運維的場景千變萬化,沒有一個產品可以在設計的時候就能滿足將來所有的運維需求。雖然自主研發能夠保證隨時調整需求,但如果任何新功能的實現都需要通過修改代碼來實現則顯然是不合理的,在成本和質量方面都難以接受。因此平臺必須具備功能可擴展性設計,在大部分場景下,通過配置就可以爲平臺增加新的功能,無需修改代碼。

基於功能可擴展性設計的理念,平臺在上線以後,平臺管理員可以根據需求在平臺上設計、配置、測試和發佈新的數據庫管理功能,在使用平臺的預置功能之上,積極參與平臺新功能的設計和建設,不斷完善平臺的數據庫管理功能。

高可用和性能可擴展性設計

目前平臺一期納入數據庫統一運維管理平臺的數據庫有上千套,隨着業務的增長,未來納管的數據庫規模會越來越大,這要求我們在設計數據庫統一管理平臺時,必須考慮規模可擴展性,平臺的各服務模塊要求無狀態,能夠橫向擴展,數據存儲平臺也需要採用分佈式存儲方案,並支持橫向擴展。

另外隨着所有數據庫的監控、運維都通過平臺來實現,平臺自身的可用性就顯得尤爲重要,因此在設計的時候要考慮高可用設計,平臺中的每個服務或組件都應該有冗餘配置,不能有單點故障的隱患。

03 平臺的主要功能

基於微服務架構,數據庫統一管理平臺實現了分層次和模塊化的功能設計,整個平臺自下而上分爲數據層,基礎服務層,功能層和展示層。

圖2-分層次的數據庫統一管理平臺功能

數據層

數據層負責存儲和管理平臺所有數據,包括CMDB數據,配置元數據,監控數據,以及數據庫日誌數據等。

  1. CMDB數據通過平臺的CMDB服務從行內統一的CMDB系統獲取,並提供了緩存和更新機制;
  2. 數據層存儲了所有從目標數據庫採集的監控數據,這些數據供平臺其它功能模塊使用,還可以發佈至Kafka供其它需要使用數據的系統使用;
  3. 數據層具備數據歸檔和清理機制,對監控數據進行聚集和歸檔,刪除超過設定保存期限的原始細粒度數據,這樣可以節省空間並提高性能。

基礎服務層

基礎服務層主要包括SQL執行服務,監控數據採集服務和數據展現服務,這些服務不直接面對平臺用戶,而是通過開放接口爲平臺上層功能或其它系統提供基礎服務。

SQL執行服務:負責到目標數據庫上執行SQL語句,所有通過平臺發起的目標數據庫訪問,無論是監控數據採集,還是用戶執行的SQL語句,都通過平臺的SQL執行服務去訪問目標數據庫,這樣可以有效控制對目標數據庫的訪問。

監控數據採集服務:根據配置的數據採集項從目標數據庫上採集各種監控數據,並進行計算和處理,然後存儲到數據層。平臺使用JDBC的方式從目標數據庫採集數據,無需在目標數據庫部署和維護Agent,同時所有的數據處理和計算都發生在監控採集服務端,因此對目標數據庫的性能影響非常小。監控數據採集服務支持高可用和負載均衡,可以通過橫向擴展的方式支持監控更多的目標數據庫。

數據展現服務:提供標準API用於訪問監控數據,這些API根據不同的使用場景組織數據,形成規範化的監控數據訪問機制。數據展現服務API除了用於平臺自身,還可以提供數據給移動運維平臺、應用性能管理平臺等其它外部運維工具或系統。

功能層和展現層

功能層和展現層面向最終用戶,提供了各種按照主題和維度劃分的數據庫管理功能,例如資源管理,性能管理,容量管理,問題管理,自動化運維等。

數據庫資源管理與CMDB系統無縫對接,提供了我行數據庫概覽視圖。在平臺中可以看到所有被納管數據庫的基本信息、運行狀態、負載以及容量使用狀況。平臺具備探活功能,會對數據庫狀態和角色進行檢查。如果數據庫無法訪問,或者數據庫主從角色與CMDB提供的信息不一致,則產生相應的問題或告警;當數據庫狀態及角色正常後,相應的問題或告警會自動解除。對數據庫資源的狀態和角色進行監控和管理一方面提升了我行數據庫的整體可用性,另一方面也爲自動化運維提供了準確的信息基礎。

圖3-統一數據庫資源管理

性能容量管理提供了從宏觀到微觀的數據庫性能容量管理體系。在宏觀層面上,通過收集和分析數據庫的關鍵性能指標,對數據庫性能進行量化評分,有效反映民生銀行數據庫系統的整體性能狀況,並且可以對某個數據庫的性能狀況進行橫向和縱向比較;在微觀層面上,對某個數據庫性能評分較低的指標項,提供下鑽分析,直接定位到相關的SQL或對象,例如等待佔比較高的SQL語句,有效讀比例較低的SQL語句,表掃描次數較多的表等,幫助數據庫管理員、應用運維人員和開發人員分析和定位問題。

圖4-數據庫性能評分

數據庫熱點分析能夠詳細展示數據庫時間分佈,同時提供了數據庫中的熱點SQL以及熱點對象,幫助用戶分析和定位數據庫性能問題根源。

圖5-數據庫熱點分析

SQL性能分析使系統中的慢SQL以及SQL瓶頸一目瞭然,提供SQL歷史執行次數及性能趨勢,同時提供SQL多指標關聯性分析,可以聚合展示SQL語句的多個指標,幫助分析和優化SQL語句;針對慢SQL,系統還可以自動分析瓶頸並給出優化意見。

圖6-SQL語句多指標關聯性分析

容量分析和預測功能可以展示數據庫容量變化趨勢,以及數據庫中表空間、表的增長率;同時容量分析功能還可以展示長期未使用的數據庫對象以及容量增長與SQL的對應關係,爲容量優化提供依據。

圖7-數據庫容量大小分佈及趨勢

圖8-數據庫容量下鑽分析

問題管理針對平臺監控和分析發現的數據庫問題,提供了問題生成、處理、驗證和關閉的完整生命週期管理。

圖9-全生命週期的數據庫問題管理體系

問題由分析引擎對採集的監控數據進行實時分析,自動生成。生成規則可以配置,並且通過規則表達式,支持複雜的條件判斷。問題管理的初衷是對所有可能導致數據庫事件的問題進行發掘和預警,因此問題項的可配置性非常重要,數據庫管理員可以根據實際經驗通過配置不斷地修正和完善問題規則。目前平臺配置了77個問題項,其中包括許多容易忽視但卻需要額外警惕的問題,例如Sequence接近使用上限、分區表可用天數過少等。

同時問題管理功能還可以記錄問題的處理過程,建立針對問題處理的知識庫體系,爲解決具體問題提供參考和指引,幫助運維人員不斷的完善和積累數據庫運維知識。

圖10-數據庫問題列表

報表服務提供了標準化和定製化的報表功能,針對不同的用戶和場景,提供了多種不同類型的報表。

深度巡檢報告:提供豐富全面的數據庫深度診斷報告。深度分析數據庫各項指標,準確反映數據庫全方位的健康情況;

彙總報告:提供多個數據庫的彙總診斷報告。從整體上分析被監控數據庫的指標狀態,主要用於對比、分析多個同類型的數據庫的運行情況;

性能容量報告:提供數據庫性能容量診斷報告。定位需要調優的SQL語句或數據庫對象,並提供專業的調優建議。對於SQL語句,提供超鏈接跳轉功能,準確定位到SQL分析頁面,提供SQL詳細分析信息。

平臺所有的報表都是根據監控數據定時自動生成或者人工觸發一鍵生成,相比於傳統的人工報表模式,節省了大量的人力成本,報表數據更加準確,覆蓋更加全面。

自動化運維功能與基礎軟件PaaS自動化執行引擎無縫集成,提供了大量的標準化數據庫運維操作,包括數據庫的啓停、參數修改、用戶權限管理、表重組、統計信息收集、表空間擴容、降低高水位等。通過平臺執行數據庫運維操作可以大大降低不規範操作帶來的數據庫操作風險。

平臺支持能夠從操作類型和管理對象兩個維度對運維操作進行權限管控,對於變更類操作,平臺還設置了客戶端白名單機制,只有授權終端纔可以進行操作。此外所有經過平臺的數據庫操作,都有相應的操作日誌用於審計,包括但不限於用戶、執行時間、執行操作、執行參數、執行對象、執行結果等,可以按照時間、操作對象、用戶等不同的維度對所有數據庫操作進行審計。

平臺的運維功能支持擴展,且不需要修改代碼。運維人員可以根據實際需求開發新的標準化腳本,通過平臺集成併發布,實現新的標準化運維操作。

04 總結與規劃

該系統一期於2019年6月4日正式上線,經過2個月時間的納管和試運行,於2019年8月12日正式向所有運維人員開放。

截止2019年10月,該平臺納管上千套生產數據庫。生產環境的使用人數共計75人,服務請求總調用超過6萬次。生產穩定的採集數據量爲1.5TB,同時採集後的數據又爲後端的智能分析提供了數據支撐。

依託於該系統的上線,我們爲數據庫運維工作提供了更便捷的工作方式,將原先老舊的半手工半腳本式的運維模式轉爲全自動自助式的運維模式;建立了完善的數據庫問題管理體系,用於發現和跟蹤各種重要非緊急類問題,有效的填補了現有監控系統的不足,與現有監控系統形成有效的互補;有效減少了審計平臺的操作次數,操作指令發送次數平均減少50%,登錄次數平均減少30%,極大的減少了非法操作的風險;建立了數據庫的報表體系,每週定期向各系統負責人發送完整的巡檢報表和問題報表,將每個系統的數據庫情況100%的暴露出來,極大的解放了手工出報表的工作量,提高了報表的覆蓋維度;提供豐富的API和數據同步功能,極大方便了我行其他系統的分析使用。

DBPaaS數據庫統一管理平臺是一個開放的平臺,在後續的工作中,我們會持續投入平臺建設,迭代開發新的功能需求;優化平臺架構,實現容器化部署,實現秒級監控和數萬目標數據庫的納管能力;在性能容量方面,實現數據庫SQL語句執行計劃管控和元數據對象管理;在自動化運維方面,實現一鍵故障診斷和一鍵故障處理,並和問題管理集成,實現基於場景化的引導式和全自動化數據庫運維操作;同時加大對國產數據庫支持力度,實現多數據庫參數比對、元數據比對、數據分佈和訪問讀傾斜分析等分佈式數據庫管理功能。在建設過程中,數據庫運維團隊成員會繼續深度參與,共同努力,持續打造民生銀行標準化、自動化、集中化和智能化的數據庫統一管理平臺。

作者介紹

朱彬:多年數據庫的運維管理經驗,目前正帶領數據庫團隊打造數據庫PaaS平臺,完成從傳統運維向智能運維的轉型。

周鵬:DBA,負責數據庫運維,數據歸檔管理平臺、基礎軟件PaaS平臺建設等工作。

本文轉載自公衆號民生運維(ID:CMBCOP)。

原文鏈接

https://mp.weixin.qq.com/s?__biz=MzUxNzEwOTUyMg==&mid=2247485152&idx=1&sn=0baf6f6e352a15efb75704fe9e5bea54&chksm=f99c649dceebed8b8151bafce5103c5419328db54c2ffdbd29e06e1375e746f5d3a515c5ff23&scene=27#wechat_redirect

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章