白屏化背後,DBA應有的資料庫自動化建設思路
一、背景
兩年多的時間裡,我們DBA Team快速完成了資料庫自動化、白屏化、閉環化、服務化的建設。 完成了JKDB資料庫自動化平臺(含元資料管理、自動化部署排程系統、監控系統、備份系統、高可用和線上切換、容量趨勢分析規劃、校驗中心等)、資料庫自助查詢平臺、許可權申請和審批平臺、自助變更執行平臺、流程引擎、工單系統、敏感資訊探測系統等等。
在這期間,除了偶爾故障和特殊支援之外,DBA 基本不需要登入伺服器去部署和操作資料。從2016年到現在,我們管理的資料庫例項大概翻了3倍,但是DBA人數基本沒有變化,目前是4個DBA維護了約1000+的SQL/">MySQL例項、1500+Redis例項,另外還維護著若干PostgreSQL / Oracle / MongoDB / Hbase叢集。
本文就將針對我們DBA Team完成的資料庫自動化平臺構建和期間的建設思路做一些簡單介紹,主要分享前期標準化構建和自動化模型搭建思路方面的部分。後續如果大家有興趣,我可以更加深入的介紹一下自動化平臺其他方面的內容。
關於資料庫標準化構建
2016年,當我入職公司時,大概經過了兩週的熟悉,儼然發現公司資料庫自動化的影子。
其一是標準化,標準化是自動化的重要前提。那個時候,我們這邊標準化是做得比較好的,從OS的標準化到DB層的標準化都有著統一的標準。比如OS的作業系統版本、檔案系統格式、磁碟掛載點、預裝軟體、核心引數等等,我們所有MySQL伺服器基本都是一致的。
這裡我們是怎麼做到保持一致的呢?
首先是我們DBA對其中一臺伺服器經過初始化設定和優化,比如按資料庫的最優策略調整核心引數,分割槽和掛在磁碟,預裝pt-tool \ MHA Node \ Xtrbackup \ Innotop \ oak-tool等資料庫常用的管理軟體,然後交付給運維同學進行打包映象,之後所有交付給DBA的伺服器都是按此映象進行部署。這樣一來,我們的OS伺服器就非常標準化了,同時也預裝了我們常用的管理工具。
我們的資料庫也有自己的部署標準,比如配置檔案標準化,除了部分可調引數是變數,其他引數全部使用標準化模板;另外像MySQL的安裝目錄、資料目錄、二進位制日誌目錄、臨時檔案目錄都有統一的標準,根據不同的例項埠來區分。
當然MySQL嚴格要做到標準化,在未做到自動化部署之前,是比較困難的,困難的不是部署技術,而是規則意識。通常一個公司都有好多個DBA共同管理資料庫,由於之前的工作習慣大家喜歡按照自己的方式來部署資料庫,或者沒有標準部署規則、有規則但是沒有嚴格遵守,都是無法做到標準化的。我們是從一開始就做了標準化規則和自動化部署指令碼,所以我們目前線上所有資料庫的部署都是標準化的,為後續自動化平臺建設打下了非常好的基礎。
例如,我們在管理機使用如下命令,則會在對應的IP伺服器上建立一個innodb_buffer_pool等於10GB的資料庫例項,埠為3306,掛載裝置為fioa,版本為MySQL-5.6.28-OS7-x86_64,資料庫編碼為utf8:
#pythonInstall_MySQL_Multi.py --ip=xx.xx.xx.xx --port=3306 --mem=10240 --device=/storage/fioa--mysql-version=MySQL-5.6.28-OS7-x86_64 --character=utf8
自動化建立的例項按照埠進行標準化部署,如下所示,某臺伺服器安裝了3306、3307、3308三個埠,則部署目錄如下所示:
配置檔案路徑: /etc/my3306.cnf /etc/my3307.cnf /etc/my3308.cnf
資料庫安裝路徑: /storage/fioa/mysql3306: binlog data mysql-error.log mysql-tmpdir /storage/fioa/mysql3307: binlog data mysql-error.log mysql-tmpdir /storage/fioa/mysql3308: binlog data mysql-error.log mysql-tmpdir
這樣部署的資料庫達到了標準化的水平,所以我們DBA只要知道IP和埠,就可以很容易地知道這個例項的所有資訊,無疑是自動化的良好基石。
二、自動化任務平臺構建
有了好的標準化基礎,我們就開始著手構建平臺了。
既然作為平臺,那麼WEB管理介面、任務排程、API服務幾個核心部分是不可以少的。下面展示一個建設初期的一個基礎架構:
如上圖所示,自上而下,系統核心部分由3層架構組成:
-
第一層為WEB控制層;
-
第二層為任務管理層和資料採集層,用於任何排程管理和資料的互動處理;
-
第三層為工作模組層,用於實現各功能的功能,比如安裝例項、配置Replication、配置MHA、建立資料庫、授權等等,這些都是由不同的底層模組來完成,通常由一系列指令碼組成。
同時系統將提供Restful API用於內部資料更新,提供HTTP API用於外部系統對接,例如和CMDB、釋出平臺等平時實現資料共享和任務對接,提供訊息通知功能用於傳送各類報警和服務類的通知功能,提供任務上報功能用於各工作模組和WEB層的資訊對接。
當然,後期我們資料庫平臺和中介軟體團隊、SA團隊、配置中心團隊完成了很多資料和功能的對接,打造了資料庫管理的閉環,例如CDMD建立好DB的資源後會通過我們的API將機器資訊推送到元資料中心,我們也會呼叫DNS平臺的服務介面來更改DNS,或者我們的平臺自動化部署完資料庫後會將域名、埠、授權使用者密碼自動推送到釋出平臺實現資料庫自動配置,開發在配置中心申請git庫時就可以同步申請資料庫等等。
通過DB平臺和公司其他部門的平臺相互打通,減少了很多人為操作環節,實現了資料庫管理閉環。
如下圖所示為我們平臺更加詳細的架構圖:
系統的核心是任務排程管理層,我們任務管理的介面如下所示,可以看到每個任務都有一個任務模組名稱,並實時記錄任務執行狀態和執行日誌:
三、關於模組化設計構建
在上面我們簡單介紹了系統的基礎架構,裡面提到了底層任務模組,比如安裝例項、建立主從模組等等,那麼這些模組底層如何優雅地設計呢?
我們平臺從開始設計時後端程式碼層就遵循高內聚、低耦合的設計思想進了模組化開發,這是我們後端設計的核心思想。
很多人在想,程式碼實現功能不就好了嗎?還需要什麼設計思想?這可能也就是開發與運維同學的思維差別。
我們知道運維同學常常忙於很多瑣碎的事情,效率優先,也習慣於指令碼化開發,可能分分鐘就寫一個指令碼實現某個功能。但是在平臺建設中,這種方式是不可取的。如果程式碼沒有規範的思想指導,當多人協同開發的過程中,很難進行專案的管理和跟進。
我們在設計時,在遵照模組化開發思想的同時,根據任務情況,設計出了任務三層排程模式,類似堆積木方式,可以很快地完成不同需求的底層任務模組,同時可維護性可非常高。另外就是複用和解耦,模組不允許同級模組相互呼叫和依賴,只允許高階模組呼叫低階模組。
如下面所示:
上面這幅圖可以很好的解釋底層的三級模組呼叫流程:
-
Level 1 為底層支援模組: 例如SSH操作模組、MySQL連線和操作模組、訊息模組(簡訊,郵件,內部資訊)、日誌模組、外部介面模組(DNS變更,CDMD同步等)、元資料維護模組(meatdata)等。
-
Level 2 為基礎單元模組: 比如安裝MySQL節點、配置主從、配置MHA、建立資料庫、DB授權等等,這些都是二級模組,基本就是完成某一個特定功能。注意Level 2裡程式碼除了業務邏輯部分,其餘只需要呼叫Level 1的模組即可。例如下面是一個安裝MySQL例項的截圖,屬於二級模組:
-
Level 3則為服務模組: 真正經常使用的模組,都是呼叫Level 2模組來進行封裝的。例如在一般業務方使用資料庫中,DBA至少需要安裝2個例項,配置個主從複製,也需要配置MHA,當然備份和監控配置也不能少。這些工作一個DBA來完成通常大半天時間過去了。那麼如果需要部署10套呢?會花費更多的時間。所以這種情況下就需要一鍵部署,一鍵通通搞定。說到這裡,還有一個問題——大家大概也注意到了安裝例項、建立資料庫等這些單一模組在Level 2模組都有,那麼Level 3幹嘛呢?其實就是呼叫Level 2就可以了。如下是一鍵部署頁面截圖,DBA填寫好提交任務即可,剩下的時候就可以處理其他工作了:
然後我們監控上報的任務日誌可以看到底層執行過程,大家可以看到任務會建立2個例項,然後配置了主從,最後配置了MHA,當然這裡面還有一些元資料維護,備份和監控開關設定等等,其實在後臺已經完成了。大概6分鐘,完成了一個DBA半天的工作,並且保證了部署的資料庫都是標準化的,不同DBA部署沒有任何差異。
再舉另外一個場景例子,通常公司對核心大業務會做TDDL分庫分表,比如十庫百表、百庫千表,需要部署在不同的物理機,這時候我們就開發了TDDL批量部署模組,基本就是封裝並行任務呼叫Level 2模組的各個模組,例如建立100個數據庫sharding的TDDL叢集,無非就是並行呼叫200次安裝MySQL例項的模組,然後呼叫100次配置主從,呼叫100次配置MHA,最後發個訊息通知。一般手工操作需要1-2天時間的任務幾十分鐘就完成了。
有了上述自動化任務排程平臺和設計規範作為基礎,我們DBA基本都很快參與進行了進行模組開發。模組開發的好處就是大家很容易上手開發,甚至之前有不會Python的同學,在簡單學習了Python之後也能照貓畫虎很快完成一個模組。
在大家的共同努力下,MySQL以及Redis日常部署和維護工作都實現了任務排程化管理。通常需要大家登入伺服器的操作現在基本都在WEB介面端就完成了。一般除了需要登伺服器定位問題和處理線上故障,基本就白屏化了資料庫管理。
這樣下來,對於整個公司而言效率高了,DBA不需要那麼多了,資料庫人為故障也少了;但對個人而言,職業工作就受到了挑戰,機會也少了,所以個人的發展只能說主要是看自己,靠自己。
最後講一點題外話,經常看到一些文章在講資料庫自動化、未來AI智慧化,預測將來DBA可能會失業。這個觀點我是二分之一認同的:隨著很多公司的自動化越來越完善,可能需要的DBA會越來越少,但我認為DBA這個崗位在任何時候都不會被淘汰。
雖然資料庫完全自動化後,難免對DBA的職業發展造成影響,但換個角度來看,留給DBA思考創新、提升自我價值的時間也更多了。其實從資料庫在公司的重要性和敏感性來看,從業務向技術轉換過程中,DBA作為資料庫的專業評審員,發揮的作用是其他崗位所無法替代的。而未來DBA應該做的,是試著轉變觀念去接收一些新事物,比如可以嘗試開發,參與到平臺開發中,或者學習一些大資料、機器學習相關的技能,又或者更深入鑽研資料庫。我相信,只要自己努力,是金子總會發光的。