隨著OCEANBASE在金融、證券、運(yùn)營商、能源等行業(yè)的應(yīng)用越來越廣泛，針對OCEANBASE的運(yùn)維支撐工具的需求也被越來越多的用戶提出來了。去年我們開始適配OB的動力來自于與一個(gè)金融行業(yè)用戶的交流，他們對我們的D-SMART支持Oracle的功能表示滿意，不過他們目前面臨了一些新的問題。那就是目前部分業(yè)務(wù)系統(tǒng)已經(jīng)從Oracle遷移到了Oceanbase，但是對于OB的運(yùn)維，他們感到有些頭痛。系統(tǒng)不出問題的時(shí)候，或者不出大問題的時(shí)候，也不太需要運(yùn)維人員介入，大部分故障場景會在短時(shí)間內(nèi)自愈。而系統(tǒng)出現(xiàn)一些較為嚴(yán)重的性能問題的時(shí)候，運(yùn)維人員往往是束手無策的，甚至不知道故障可能會持續(xù)多長時(shí)間。

D-SMART支持OCEANBASE的適配工作已經(jīng)經(jīng)歷了一年多了，當(dāng)時(shí)適配的版本是3.X，不過到了Oceanbase 4.2.1 GA的23年10月份，這個(gè)工作還沒有徹底完成。通過一個(gè)運(yùn)維平臺，不斷的積累運(yùn)維經(jīng)驗(yàn)，構(gòu)建大量的自動化預(yù)警模型和分析工具，可以有效的增強(qiáng)對OB數(shù)據(jù)庫的運(yùn)維支撐能力，整個(gè)智能化運(yùn)維的框架是十分成熟的，研發(fā)團(tuán)隊(duì)對Oceanbase的研究何跟蹤也有一兩年時(shí)間了。因此我們在去年年初開始立項(xiàng)針對OB進(jìn)行適配的時(shí)候，原本以為這項(xiàng)工作會在3-4個(gè)月內(nèi)初步完成，然后去某個(gè)用戶處磨合。沒想到適配OCEANBASE遠(yuǎn)比我們預(yù)料的復(fù)雜。分布式數(shù)據(jù)庫與集中式數(shù)據(jù)庫在很多地方都與集中式數(shù)據(jù)庫不同，從而導(dǎo)致運(yùn)維管理方面的差異是十分巨大的。

首先是指標(biāo)體系的不同，分布式數(shù)據(jù)庫的部署環(huán)境是一組服務(wù)器，數(shù)據(jù)庫實(shí)例也是由一組OBSERVER組成的多個(gè)分布式的服務(wù)組成。因此指標(biāo)體系完全不同。對于集中式數(shù)據(jù)庫來說，我們可以關(guān)注某個(gè)指標(biāo)，比如每秒CLOG數(shù)量。不過對于OB來說，這里就復(fù)雜了，因?yàn)槊總€(gè)OBSERVER都會有相關(guān)的指標(biāo)。

在集中式數(shù)據(jù)庫中的一個(gè)指標(biāo)，在分布式數(shù)據(jù)庫中可能會有很多值，分布式數(shù)據(jù)庫集群的節(jié)點(diǎn)數(shù)量越多，這個(gè)指標(biāo)的值就越多。不僅如此，Oceanbase還支持多租戶，每個(gè)租戶都有獨(dú)立的指標(biāo)，因此在一個(gè)Oceanbase數(shù)據(jù)庫中，某一個(gè)指標(biāo)的值可能有幾十個(gè)甚至幾百上千個(gè)。我們不能僅僅從總值或者平均值去看問題，還要考慮值的均衡性問題和變化趨勢。因此運(yùn)維監(jiān)控工具需要具備對一組值的處理能力。這涉及到了對D-SMART底層指標(biāo)處理體系的改造與優(yōu)化。

前端界面上顯示的值也是要斟酌的，到底把哪個(gè)值放上去呢？最大值，平均值？如果放最大值有可能同一行上面的數(shù)據(jù)來自于多個(gè)不同的OBSERVER，數(shù)據(jù)時(shí)不一致的。

因?yàn)镈-SMART最早設(shè)計(jì)指標(biāo)體系的時(shí)候就學(xué)習(xí)了互聯(lián)網(wǎng)企業(yè)的經(jīng)驗(yàn)，支持列表、表格等模式，因此只要在前端顯示與后端處理的時(shí)候適配一下就可以了，更大的問題還在后面。

第二個(gè)需要考慮的問題是多租戶的問題，Oceanbase是一個(gè)從底層到上層都支持多租戶的數(shù)據(jù)庫系統(tǒng)。不同的租戶之間有著較強(qiáng)的隔離。因此從運(yùn)維的角度，我們?nèi)绾蝸砜创汉妥鈶裟?？對于一個(gè)數(shù)據(jù)庫來說，從集群下鉆到租戶，再到某個(gè)OBSERVER，可能是我們從集中式數(shù)據(jù)庫沿用下來的思考方式。但是這種模式似乎會讓運(yùn)維工具變得太復(fù)雜，讓運(yùn)維人員很難掌握。通過思考，我們決定把集群和租戶都看成是一個(gè)獨(dú)立的運(yùn)維對象。在現(xiàn)實(shí)的生產(chǎn)環(huán)境中，有些用戶對于Oceanbase的運(yùn)維也是這樣的，集群有專門的人員維護(hù)，而不同的租戶交給不同的使用單位自己來運(yùn)維。

因此我們?yōu)镺ceanBase設(shè)計(jì)了三種數(shù)據(jù)庫子類型：Oceanbase集群子類、Oceanbase MySQL租戶子類和Oceanbase Oracle租戶子類。如果僅僅以租戶的角度來看待Oceanbase這樣的多租戶數(shù)據(jù)庫系統(tǒng)還是比較簡單的，這個(gè)框架完全可以參考Oracle的PDB，事實(shí)上root租戶我們可以把它看成是Oracle的CDB，我們把root租戶看成是Oceanbase的集群，對于集群而言，我們更關(guān)注的是節(jié)點(diǎn)、資源（總體與可分配資源）、容量、網(wǎng)絡(luò)、高可用、故障等問題。而不需要去關(guān)注負(fù)載、并發(fā)等方面的問題。

Oceanbase數(shù)據(jù)庫的負(fù)載、并發(fā)、性能等方面的問題可以在租戶層面去關(guān)注。不過Oceanbase擁有MySQL和Oracle兩種兼容性租戶，這兩種兼容性租戶的核心代碼是有較大差異的，因此這兩種租戶在指標(biāo)方面都不是拉齊的。比如等待事件只有Oracle租戶才有，某些MySQL租戶的指標(biāo)在Oracle租戶中不見得有，因此我們無法對這兩種租戶采用相同的指標(biāo)和健康模型。

第三個(gè)問題是Oceanbase自身的問題引發(fā)的，那就是Oceanbase不同大版本的兼容性問題。這是一個(gè)十分值得吐槽的問題，每次Oceanbase大版本升級，其系統(tǒng)視圖，指標(biāo)體系，等待事件都會有較大的變化，運(yùn)維工具必須做較大的調(diào)整。

第三個(gè)問題疊加第二個(gè)問題，讓Oceanbase的智能模型構(gòu)建也變得復(fù)雜了，考慮到目前Oceanbase的大多數(shù)用戶還是在使用3.x版本，因此我們必須對3.x版本進(jìn)行支持。2.x版本的支持可能要往后放一放了，因?yàn)?.x和3.x版本的差異依然巨大。在這種情況下，健康模型要根據(jù)三種子類分別根據(jù)4.X/3.X版本進(jìn)行個(gè)性化定制，目前通過7個(gè)模型來覆蓋這些版本。

3.x和4.x版本之間的差異遠(yuǎn)遠(yuǎn)比增加一倍的健康模型要復(fù)雜的多，指標(biāo)體系中也存在了大量的不兼容的指標(biāo)，甚至描述同一個(gè)問題的指標(biāo)會出現(xiàn)2個(gè)，一個(gè)代表4.X版本，一個(gè)代表3.x版本，而二者無法完全兼容，因?yàn)楹x并不一定完全一致，如果用同一個(gè)指標(biāo)來表示，很容易產(chǎn)生誤解。

第四個(gè)問題是集群與服務(wù)器節(jié)點(diǎn)之間的拓?fù)潢P(guān)系問題。一套大型的Oceanbase數(shù)據(jù)庫可能由數(shù)十個(gè)甚至上百個(gè)節(jié)點(diǎn)組成，并且上面跑了數(shù)十個(gè)租戶，這種拓?fù)潢P(guān)系十分復(fù)雜。雖然租戶之間但是他們依然存在關(guān)聯(lián)關(guān)系，因?yàn)樗麄児蚕砑褐械乃蟹?wù)器。服務(wù)器出現(xiàn)故障或者性能問題，可能會導(dǎo)致集群和租戶出現(xiàn)出現(xiàn)問題。因此我們在運(yùn)維Oceanbase的時(shí)候依然必須關(guān)注服務(wù)器的健康。但是把服務(wù)器如何被納入監(jiān)管呢？

最終我們的方案選擇了服務(wù)器在運(yùn)維管理臺上隱身，通過集群拓?fù)淙肟趤斫y(tǒng)一監(jiān)控集群所依賴的服務(wù)器的方案。服務(wù)器出現(xiàn)異常時(shí)，健康模型與故障模型會發(fā)現(xiàn)其問題并主動報(bào)警，但是服務(wù)器并不出現(xiàn)在數(shù)據(jù)實(shí)例的監(jiān)控清單里。不過在集群和租戶的集群拓?fù)淅镂覀兛梢钥吹剿蟹?wù)器的健康狀態(tài)，如果需要，可以進(jìn)行下鉆。采用這種方式后，當(dāng)服務(wù)器沒有故障或者隱患時(shí)，我們可以不去關(guān)注服務(wù)器，只要關(guān)注租戶的健康，而當(dāng)服務(wù)器存在隱患時(shí)，我們可以獲得告警，并且有入口可以去做診斷分析。

經(jīng)過這一年多與Oceanbase的深度接觸，我們找到了一種對復(fù)雜的多租戶分布式數(shù)據(jù)庫的運(yùn)維監(jiān)控與故障定位的方法，Oceanbase專版的發(fā)布后，我們會邀請客戶一起來進(jìn)行測試，并通過對用戶現(xiàn)場數(shù)據(jù)的分析，豐富故障模型，完善智能基線，并積累更多的運(yùn)維知識工具。通過數(shù)年的積累，我想Oceanbase的運(yùn)維知識積累會一步步的豐富起來。