一站式運維管理工具平臺 OCP 到底有多好用，看這篇文章就夠了

作者簡介：雪染，OceanBase 技術專家。

1.OCP 是 OceanBase 一個一站式運維管控平臺。

OceanBase 擁有很強大的功能，但當單獨使用 OceanBase 核心時，對使用者的要求比較高，使用者使用並不方便。甚至某些功能的實現，非常依賴於特定工具的配合。比如想要知道 OceanBase 一段時間的QPS, 系統表內無法直接獲取，系統表中只記錄累加之後的值，需要特定工具持續採集，並持久化這些原始資料才能進行計算。

所以更好的使用 OceanBase 離不開生態工具的配合，OCP 應運而生。

除了 OCP，還有一些其他的工具來支援 OceanBase，比如 OBD 可以做部署和日常運維，OBAGent + Prometheus + Grafana 可以做監控，這些工具都非常好用。

但是每個工具都只滿足特定一部分的需求，在滿足日常的生產環境使用時，運維人員需要使用多個獨立的工具，非常繁瑣耗時耗費精力。而 OCP 可以類比於軟體開發中的 IDE 開發環境，在一個環境裡提供了最常用的功能， 滿足絕大部分日常的使用場景。

OCP的主要功能分為以下三個部分：（表）

①   OceanBase運維。

• OceanBase叢集的安裝部署和日常運維。
•  租戶管理。
• Database 管理。
• OceanBase 相關生態工具的運維，目前已經支援 Obproxy。
• 主機和軟體包的管理, 是最基礎的運維能力，為運維 OceanBase 提供支援。

②   OceanBase 監控。

• Metric監控指標，包括 OceanBase 和 Obproxy 的監控指標。
• SQL 統計分析，慢 SQL 分析。
• 基於監控指標/日誌的報警。

③   後設資料查詢服務。

• 儲存並實時更新 OceanBase 的rootservice地址。
• 提供給其他元件查詢 OceanBase 的rootservice地址。
• 記錄 ObProxy 和 OceanBase 的關聯關係。這是在前面基礎上做的一個能力。

OCP 的應用場景。

①  內部使用：比如螞蟻內部、阿里集團內部很多機器需要管理，需要標準化管理的平臺來支援大規模的管理，讓 DBA 專注於更有價值的事。

②  獨立輸出：為企業使用者提供企業級的管理服務。

③  雲上使用：將 OceanBase 以雲服務的方式提供給使用者。

2. OCP系統架構

上圖為 OCP 的系統架構，其主要模組有三：

①  OCP 管理服務：它包括一個由 Java 實現的應用程式，實現 OCP 平臺的主要邏輯。它會與其他元件互動，對外提供 http服務。管理控制檯提供給使用者前端頁面進行互動，其他系統也可以通過 open api 直接呼叫 OCP。

②  資料庫儲存：包括元資訊資料庫和監控資料庫。其中元資訊資料庫儲存 OCP 管理資源的記錄，監控資料庫儲存 OCP 採集的一些監控指標，包括採集到的原始值以及計算後的統計資料。

③  OCP-Agent：它部署在每個 OCP 管控的主機上，提供兩種能力。 首先，提供運維介面，OCP 需要進行的運維操作通過呼叫 OCP-Agent 來實現，也通過這種方式，實現跨平臺的能力； 另外，提供監控能力，包括以服務的形式通過 Prometheus 協議提供 metric 資料，以及主動上報 SQL 相關的資料。

3. OCP 主要功能模組以及實現

3.1 運維模組

OceanBase 作為分散式資料庫，相對於傳統的單機資料庫更加複雜，在運維上面臨了諸多挑戰：

①  需要管控的節點很多；節點是以一定的層次關係組織在一起的，在運維過程中需要考慮到 OceanBase 的各種限制，比如不能破壞多數派，導致運維流程比較複雜。

②  運維任務耗時長；一個運維任務會包括很多步驟，這些步驟之間有一定的依賴關係，不能完全並行執行，此外，一般運維的步驟會有涉及到主機上的一些操作，相對比較耗時。

③  任務在任何步驟都可能失敗；一般運維任務都是需要在管理的主機上進行一些操作，首先，當管理的主機規模大了之後，遇到主機的故障就不再是一個小概率事件，另外，主機上環境並不都是標準的，可能會遇到各種環境相關的問題，都會導致任務失敗。

④  OceanBase 在快速的迭代更新，存在很多版本，這些版本之間也會存在差異，需要考慮各版本的相容性問題。

⑤  使用者可能會使用不同作業系統的主機，運維的方式存在差異，需要考慮跨平臺能力。

那麼， OCP 是如何來解決以上痛點呢？

①  定義原子化的任務；支援正常執行、回滾、重試、跳過這些操作。然後基於原子任務通過編排的方式構造出一個完整的任務，可以實現複雜的運維邏輯，而且，原子任務可以在多個運維場景中得到複用，避免重複開發。

②  針對任務執行時間長的痛點；首先，在編排任務的時候會盡量將不相關的任務進行並行化處理，另外，任務提交之後會在後臺執行，只有在失敗的時候才需要再介入處理。

③  針對失敗的任務；依賴原子任務提供的能力，可以進行重試或放棄。

④  針對OceanBase多版本相容；OCP 實現了 OB-SDK，將不同版本的差異在 OB-SDK 中處理掉，對外提供標準的介面，從而遮蔽掉不同版本的差異。

⑤  主機跨平臺的能力是通過 ocp-agent 來實現的；也是通過將不同平臺的差異在 ocp-agent 中處理掉，對外提供標準的介面。

⑥  OCP 提供了任務流程的視覺化；將整個任務的關係以列表/圖表的形式展現出來，使用者可以從圖表中獲知哪一步執行了什麼任務、哪些步驟失敗了等等，然後進行處理。

上圖展示 OCP 運維功能涉及到的主要模組。

使用者請求按照業務邏輯由不同的 service 服務進行處理，根據請求構造對應的任務模版和引數然後將其提交給任務引擎，任務引擎會生成 task 例項然後執行，task 中涉及到的操作，根據運維物件的不同，會選擇不同的方式進行操作。除手動提交的一次性任務之外，還會有一些需要定時排程的場景，這部分由排程模組來負責，排程模組記錄了需要排程的任務模版，引數以及排程策略，當到達排程時間的時候，會向任務引擎來提交。

任務引擎負責任務的執行，是整個運維模組的關鍵，對外，任務引擎提供了任務的建立、取消、重試、回滾和跳過介面，對應了實際運維中的場景，當任務通過建立介面提交給任務引擎之後，任務引擎會根據任務模版和引數來生成任務例項，任務例項是有多個原子任務例項按照一定的關係來組織的，可以用一個 DAG 圖來表示，任務的執行就是按照 DAG 圖的順序來執行其中的原子任務，這部分會由 Task Executor 中的 worker 執行緒來執行，任務的引數定義在 context 中，context 會在原子任務之間傳遞。

上圖展示 OCP 中的運維任務，有兩種展示形式，一種列表形式，一種圖的形式，都可以非常直觀的展示出任務的整體結構，當前執行進度這些資訊。

任務過程中遇到失敗或者異常的情況，可以根據實際情況選擇重試或者回滾，都是從當前失敗的節點處開始執行的，重試操作會重做當前的原子任務，成功之後繼續向後執行，回滾操作會按照任務執行相反的順序，從失敗節點向前依次回滾掉所有執行過的原子任務。

3.2 監控模組

OCP 另外一項非常重要的功能是 OceanBase 的監控功能, 對於掌握 OceanBase 的執行狀態，保持系統的穩定執行，以及問題分析非常有幫助。

監控OceanBase也面臨著諸多挑戰：

①  監控的節點多。

②  指標的維度多，OceanBase 有許多邏輯概念，比如 zone，租戶這些都會對應到指標的維度上。

③  資料型別不盡相同，即包括 Metric 型別的資料，也有 SQL 這種不怎麼標準的監控資料。

④  需要能方便的新增或修改指標以適應 OceanBase 版本變化帶來的改變。

⑤  可運維性,監控系統需要多個元件來配合使用，節點多，鏈路長，也是對運維人員的一個考驗。

⑥  高可用，監控系統需要長時間穩定執行，必須考慮服務高可用的方案。

那麼， 如何通過OCP 來解決以上痛點呢？

①  Agent 程式部署在管理的主機上，伴隨著主機的全部生命週期，agent 負責採集所在主機的監控資料，降低了採集端的資料規模。

②  Agent 端實現 Prometheus 協議的 exporter，server 端實現了相容 Prom-QL 語法的查詢引擎，指標的維度通過 label 表示，在聚合計算的時候再按照 label 聚合。

③  提供兩種資料採集模式，適配不同場景。對於 metric 資料採取拉的模式，由 ocp-server 主動向 agent 拉取資料，而 SQL 採取推的模式，由 agent 主動將資料推送到 monitordb ,再由定時任務執行之後的聚合計算。

④  資料採集和計算邏輯通過配置來實現，有指標變化時，不需要修改程式，只需要修改配置即可。

⑤  使用 OceanBase 做儲存，首先，OceanBase 本身是一個高可用的資料庫，提供了資料的高可用保障。另外，減少了對其他元件的依賴，保證運維能力可控。

⑥  高可用的部分，基於分散式鎖實現HA，有節點故障的時候可以實現自動切換。

    Metric 型別的指標使用 prometheus 協議，這是監控中常用的一種指標，OCP 為減少對外部元件的依賴，自己實現了監控指標的拉取、解析、儲存以及聚合計算的邏輯。SQL 型別的指標是一個相對比較定製化的採集計算邏輯，在本文中只介紹 OCP 如何來處理 metric 型別的指標資料。

整體的監控鏈路如上圖所示，在主機上都部署 ocp-agent, 其中 ocp_exporter 程式負責 metric 監控指標的採集。根據主機上部署的程式的不同，它會採集不同的監控指標。比如上圖的 Server2 上，主機上沒有其他服務，就只需要採集主機。而 Server1 部署 OBProxy、OB，就會同時採集這些服務的監控指標。 ocp_exporter 的地址會在運維任務中寫入到 ocp

的 metadb 中，包括對應各個服務的請求地址，期望的請求週期。

ocp-server 有定時邏輯，會按照配置的頻率來生成採集任務，採集 exporter 的資料, exporter 返回的資料包含了所有邏輯查詢維度作為 label，下圖展示了 ocp_exporter 返回的資料的樣例。 

ocp 上可以靈活的指定查詢維度，對應的，需要這些資訊包含在原始的資料中。

Exporter 的資料採集到以後，會被放到佇列中，進行非同步解析、快取和儲存。ocp-server 中的資料是按照採集週期分級的，按照常用的時間查詢維度，分為秒級、分鐘級、小時級和天級別, ocp-server 採集到資料之後先記錄在快取當中，然後再定期寫入到資料庫中，為避免重複的採集，細粒度的監控指標已經採集過，就不會在粗粒度的採集任務中再重複採集，ocp-server 定時的進行取樣，寫入到粗粒度的快取中，最終會寫入到資料庫對應的表當中。

Metric 指標的監控查詢需要將採集到的原始指標按照請求的維度進行聚合，OCP 實現支援 Prom-QL 語法子集的查詢引擎, 由於採集到的資料首先放在 ocp-server 的快取當中，定期重新整理到資料庫中。如果要查詢最新的資料，一定要通過採集節點來讀取快取和資料庫中的資料，合併之後再進行聚合計算，這樣會帶來一個問題，採集和計算是在一個單節點上進行的，其他節點只是作為備用節點，只有當發生切換的時候才啟用提供監控服務，監控服務的主節點就很容易成為瓶頸，這部分的優化在目前已經在做，會修改成每個 ocp-server 節點處理一定數量 exporter 的資料，充分發揮多節點的能力。

3.3 OceanBase 配置服務

OceanBase 配置服務是 OCP 提供的 http 服務，一般被叫做 config server，支援增刪改查操作。 當 OceanBase bootstrap 或者之後 rootservice 地址發生了變化的時候，會把自己最新的 rootservice 地址向 OCP 註冊，OCP 記錄這個叢集之後，還會有後臺任務主動更新 rootservice 地址， 以保證 OCP 中儲存的記錄是最新的。其他元件如 OBProxy、OMS、Java Client、Table API Client 想要訪問 OceanBase ，首先需要知道 rootservice 的地址，可以通過請求 OCP 來進行查詢。

在生產環境中，如果想要同時訪問多個 OceanBase 叢集，一般只能使用 config server 的方式，可以查詢到 OceanBase 叢集列表和 rootservice 地址資訊。以 obproxy 為例，如果通過配置 rs_list 的方式啟動，obproxy 只能連線一個叢集，而且在極端情況下，當叢集的 rootservice 都發生變化的時候，會造成無法連線，而使用 configserver 可以獲取到叢集的列表，obproxy 可以連線多個叢集，而且 rootservice 的地址會保證更新到最新的值，可以避免無法連線到 OceanBase 的情況。OCP 也支援管理 obproxy，可以在此基礎上再做一層控制，維護 obproxy 和 oceanbase 叢集的對應關係，可以很方便的做訪問控制。

由上圖可以看出，obproxy 啟動引數中傳入 obproxy_config_server_url 這個引數，obproxy 請求這個地址，可以獲取到可以連線的 OceanBase 叢集列表，已經 OceanBase 叢集的config server 地址，再通過訪問 OceanBase 叢集的 configserver 地址，得到真實的 rootservice 地址。

在生產環境中，如果想要同時訪問多個 OceanBase 叢集，一般只能使用 config server 的方式，可以查詢到 OceanBase 叢集列表和 rootservice 地址資訊。以 obproxy 為例，如果通過配置 rs_list 的方式啟動，obproxy 只能連線一個叢集，而且在極端情況下，當叢集的 rootservice 都發生變化的時候，會造成無法連線，而使用 configserver 可以獲取到叢集的列表，obproxy 可以連線多個叢集，而且 rootservice 的地址會保證更新到最新的值，可以避免無法連線到 OceanBase 的情況。OCP 也支援管理 obproxy，可以在此基礎上再做一層控制，維護 obproxy 和 oceanbase 叢集的對應關係，可以很方便的做訪問控制,在 OCP 頁面上可以直接修改 obproxy 可以連線的叢集列表，修改後會影響 configserver 返回的 OceanBase 叢集列表，當 obproxy 重新整理到新的列表之後，就會生效。

4.OCP 實際應用注意事項

4.1安裝部署

安裝部署是使用所有軟體的第一步。

• OCP基於 docker 釋出，需要 docker 環境。
• 資料庫使用 OceanBase，可以通過 OBD 拉起。
• OCP 所需的資源主要由監控模組決定，監控資料的規模和管理的主機數量有關係，另外也和 OceanBase 叢集中租戶的數量有關係，需要事先做好評估，以免資源緊張造成的各種問題。

4.2高可用規劃

OCP 是一個非常重要的元件，尤其是 config server 服務，它為我們在生產環境其他元件提供連線 OceanBase 的入口。因此 OCP 的高可用也是一個非常重要的考量。

• OCP 的狀態都是通過後設資料庫來維護的，因此後設資料庫需要是高可用的，一般是多節點的 OceanBase 叢集。
• OCP 程式本身雖然是無狀態的，但是為了持續提供服務，需要部署多個節點。
• 其他元件，比如連線後設資料庫的 obproxy 也是需要多個節點部署。

4.3常見使用問題

當前 OCP 在一些使用場景中，有一些預設的假設，因為它本來是在內部使用的一個產品，然後慢慢地放到開源社群使用，使用者在使用過程中可能會因不清楚預設的假設導致使用出現問題。以下列舉一些常見的問題。

• admin 使用者不存在。這是由於 OCP 在內部使用過程中，有規範要求要有 admin 使用者，並且在 rpm 打包時，也是把程式預設安裝在了 homeadmin 目錄下。但是在開源的使用場景中，使用者可能並沒有遵循這種規範。因此首先建立 admin 使用者就可以避免這種問題。
• 缺少依賴，部署 OceanBase 的時候會依賴 mysql 命令來 bootstrap ，obproxy 守護指令碼中，會依賴 nc 去檢查 obproxy 是否正常,一般任務失敗時會有明確的日誌，安裝對應的依賴重試即可。
• 路徑許可權問題。如果之前手動修改了許可權或是新接管的叢集，它不是由特定 使用者啟動的，會導致出現路徑許可權的問題。
• 任務失敗了怎麼辦。這些問題會在任務日誌中有詳細的體現。但是對於一個失敗的任務來說，建議先點選這個失敗的節點，檢視它失敗的原因。一般來說 失敗的原因是比較明確的，比如缺少依賴，只需補充安裝依賴就可以了。當這些處  理完之後，可以對這個任務進行重試。當然如果這個任務不需要重試，也可以直接跳過。
• 失敗的任務一定要先處理掉，才可以對相同的資源發起新的任務，避免互相影響。
• OCP 認為叢集是一個管理的最小單元，許多配置會在叢集維度生效，比如 OceanBase 的安裝路徑，在同一個叢集中是要求一致的，在實際使用中，也推薦至少一個叢集中使用的機器資源，配置都相同，避免不必要的環境問題。

4.4      OCP 一些好用的功能

使用者和許可權管理

作為企業級的管控平臺，使用者和許可權管理是必不可少的，OCP 中可以按照角色來劃分許可權集合，使用者可以通過與角色關聯來靈活的配置許可權，除了系統預設的角色外，還支援使用者來自定義。OCP 中每個使用者都有自己專屬的密碼箱，用來儲存各類資源的憑證，使用者之間相互隔離，既方便又安全

Topo / 資源分佈圖

OCP 中以直觀的形式展示了 OceanBase 的資源分佈，叢集和租戶都有 topo 圖的展示，並且可以直接在上面發起運維操作，減少使用者的理解成本。

資源分佈圖會展示出更多更詳細的資訊，精細到租戶的 unit，可以直接在這裡發起 unit 的遷移操作。

————————————————

本文視訊回放連結  

OceanBase 社群版 OCP 功能解讀

附錄：

練習題：

實踐練習一（必選）：OceanBase Docker 體驗 

實踐練習二（必選）：手動部署 OceanBase 叢集 

實踐練習三（可選）：使用OBD 部署一個 三副本OceanBase 叢集 

實踐練習四（必選）：遷移 MySQL 資料到 OceanBase 叢集 

實踐練習五（可選）：對 OceanBase 做效能測試 

實踐練習六（必選）：檢視 OceanBase 執行計劃 

還沒交作業的小夥伴要抓緊啦！

可以免費 帶走 OBCP 考試券喔~~

方法一： 完成四道必選練習

方法二： 任意一道練習題 ➕ 結業考試超過80分

已經有很多同學搶先答題了，

加入釘釘群（群號3582 5151），和大家一起學習、交流～～

進群二維碼：