作者   郭旭瑞·沃趣科技產品專家

出品   沃趣科技

｜序 言

標題中的DBA其實包含兩層含義：Database Architect 與 Database Administrator，我在這裡都簡稱DBA了。

作為Database Architect，我關注：

• 我要建設的資料庫服務應該提供什麼樣的效能與容量，並且滿足3~5年的業務增長？
• 為了達到我要的效能與容量，我應該匹配什麼樣的硬體？
• 資源的整合/分配/隔離。
• RTO & RPO

沃趣在企業級市場耕耘良久，在一些大的企業，IT系統通常以巨石型或者說是煙囪模式進行建設，系統的新建或改造都要經歷需求提出、可行性研究、需求確認，經歷這三個階段，最終的硬體、架構選型才得以確定；接下來進入到招投標、商務洽談、採購，這個時候硬體或者說基礎設施才拿到手中；最後經過相應的安裝、部署、測試才能最終上線執行。整個過程可能持續半年甚至更久。

對於Database Architect而言，往往對於下面這幾個問題比較頭痛：

• 巨石型IT架構往往服務於單個業務，但在規劃初期，預留了3~5年甚至更長的效能、容量增長餘地，較低的資源利用率造成了資源的嚴重浪費，企業總體擁有成本(TCO)不合理。
• 冗長的系統上線流程，造成系統在遭遇系統突發瓶頸時無法快速擴充套件，導致業務增長受限。
• 系統建設、選型、採購、上線所帶來的大量重複性的工作耗費了大量的人力、物力，造成人的精力不能更多地放在業務創新上。

作為Database Administrator，我關注：

• 安裝和部署
• 運維管理、變更
• 監控(效能、空間、日誌)
• 可用性
• 資料安全(備份與容災)

對於Database Administrator而言，往往對於下面這幾個問題比較頭痛：

• 安裝部署複雜，從硬體組裝到OS安裝到資料庫軟體的部署
• 資料庫手動管理，易出錯
• 監控、備份指令碼化，手動編寫、維護、推送指令碼。每天早、中、晚執行指令碼，檢視效能狀態及日誌資訊，缺乏監控資料的集中式彙總歸檔與便捷地資料回溯，無法從多維度觀察效能的歷史變化趨勢；備份通過定時任務執行，每天需要確認備份成功與否
• 資料庫發生故障時，手動切換，人的反應時間嚴重影響業務中斷時間
• 當然，預算充足的企業可能會採購一個個IaaS平臺、監控平臺、運維管理平臺、高可用切換軟體、備份平臺等等，但無疑付出了高昂的成本，各平臺累積起來學習成本巨大且互不關聯

綜上，資料庫工作者希望有一個完美的資料庫執行平臺，涵蓋如下幾個方面的特性：

• 資源按需分配：資料庫資源快速方便獲取併合理分配，而且高度彈性可擴充套件
• 高效能高可用：提供高效、穩定的計算、儲存資源及容錯能力
• 方便易用：監控管理輕鬆、方便、快捷
• 資料持久安全：統一的備份及有效性校驗，保障平臺極端故障場景下資料庫可恢復
• 成本合理：在合理的成本預算下，實現以上所有功能的有機結合

｜資源排程

巨石型架構是一種常見的IT架構，從需求的提出到資源就位，人力、時間成本巨大。資源獨佔一方面帶來資源的嚴重浪費，另一方面也意味著資源在使用緊張時無法彈性擴充套件。

舉個很簡單的例子，某電商平臺，雙11交易量是平時的100倍。那麼問題來了，系統是按照平時的交易量來做規劃，還是按照雙11的交易量來做規劃？如果按照平時的交易量來規劃，那麼雙11當天如何緊急擴容，過了雙11，硬體資源如何處理？如果按照雙11的交易量來規劃，那就意味著平時要浪費99%的資源，這個成本從哪出？這是一個普遍存在的問題，資訊化在企業中已經發展了很長時間了，大大小小系統都是以這種方式在構建，IT預算逐年增加，這看似一個難解的局。

雲，通過資源整合，提供了一個按需分配、靈活擴充套件的資源管理方法。在巨石型架構中，一臺伺服器是最小的資源排程單元；但在雲上，一臺伺服器的資源可以被靈活拆分，多臺伺服器的資源可以被動態整合。

在雲上，一切隨需隨取，我不需要在一個系統建立初期就賦予它3~5年的效能餘量；在系統業務發生波動甚至急劇增長時，雲上都有足夠彈性的資源作保障。還是剛才提到的場景，電商企業大大小小的系統如果部署在雲上，在經歷雙11時，除電商核心業務之外的系統完全可以出讓一部分的計算資源甚至停擺一天，保障電商核心業務的使用體驗。在大規模計算領域，通過雲的彈性特徵進行離線上混合部署，是一種非常好的資源利用最大化的手段。

基於Kubernetes + Docker的QFusion 3.0資料庫雲平臺很好地實現了雲的這一特性，藉助容器這一輕量級虛擬化技術甚至可以做到資源的高密度整合，相比基於Hypervisor的虛擬化技術，實現資源的更高效利用。

在Kubernetes上，容器是最小的資源分配單元。

下面這個配置就是一段申明式地在原生Kubernetes上建立一個業務應用的邏輯的一部分，你只需要把這個配置提交給Kubernetes，一個MySQL資料庫例項就被創建出來了。“上帝說，要有光，於是便有了光”，Kubernetes上定義了一些基礎的資源以及API，讓一切都變成所見即所得，在Kubernetes上，這樣的“優雅”的設計處處可見。

containers:
- name: db
image: mysql
resources:
  requests:
    memory: "64Mi"
    cpu: "250m"
  limits:
    memory: "128Mi"
    cpu: "500m"

可以看到，這段配置建立了一個容器(其實是Kubernetes中Pod概念的一部分，Pod的概念在此不詳述，大家理解為容器也不會錯)，包含一個MySQL容器，並通過resources對容器的CPU、Memory等資源進行限定。當業務負載升高時，通過對resource進行修改，進行計算資源的擴充套件。同時，通過resource亦可以定義資源的優先順序進行資源隔離和QoS。

對於kubernetes resource的介紹，等讀完本文走傳送門：  https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-types 

https://medium.com/google-cloud/quality-of-service-class-qos-in-kubernetes-bb76a89eb2c6

｜快速部署

聊到快速部署，Docker提供的映象絕對是神一樣的設計。 

有人舉了很形象的例子，Java出現之前，不同OS平臺上需要寫幾套不同的程式碼，JVM的出現實現了程式碼執行的平臺無關性，“Write once,run anywhere”；而軟體的部署也是依賴平臺的，Docker engine與Docker映象解決了軟體部署的平臺無關性，”Build once,run anywhere,Configure Once,run anything“。

在資料庫的部署過程中，依賴包、核心引數、使用者與組、目錄等等一系列前置條件都需要DBA人工或指令碼方式進行操作，大量重複性無意義的時間、精力消耗。docker的映象便是將這所有的一切配置進行打包，一個映象就是一個容易分發的即啟即用的應用，與資料庫結合後一個映象就是一個迅速部署、即啟即用的資料庫。

｜高效能

各種基於虛擬機器技術實現的IaaS平臺開啟了雲端計算時代，在這種平臺上，虛擬機器是資源排程的單元。每一個虛擬機器都安裝、執行一個Guest OS，糟糕的是，Guest OS本身會消耗很多CPU和記憶體。更糟糕的是，在虛擬化技術中，CPU、Memory、IO都是由Hypervisor軟體來模擬的，這就意味著應用程式在使用這些資源時，在Hypervisor這一層會產生額外的資源開銷。

容器作為下一代、輕量級虛擬化技術，容器中的應用是在宿主機的核心上執行的，它有著比只能通過Hypervisor訪問宿主機資源的虛擬機器有著更好的效能。CPU、Memory、IO都是以本地方式直接使用的。

下圖分別是我們在虛擬化與容器環境中對IO延遲所做的對比：

基於相同的伺服器與儲存裝置，虛擬化環境中的讀延遲是容器環境的15倍(讀者可以在自己的環境中進行驗證)。

基於相同的伺服器與儲存裝置，虛擬化環境中的寫延遲甚至能達到容器環境的62倍(讀者可以在自己的環境中進行驗證)。

資料庫需要對資料進行儲存、提取、計算，既屬於計算密集型負載，更屬於IO密集型負載。資料庫容器化可以顯著的提高資料庫例項的效能、部署密度和計算資源利用率。

資料庫OLTP場景下的效能對比測試：

虛擬化：

容器化： 

基於相同的硬體資源，容器化資料庫的QPS可以做到虛擬化環境的2.5倍，Latency降低50%以上。提供更高系統吞吐量的同時，保證更高的服務質量。

｜高可用

資源動態分配、經濟高效是Kubernetes、Docker的原始屬性，但他們並不能理解什麼是資料庫的高可用，這就是QFusion 3.0 RDS平臺需要重點發力的地方。QFusion 3.0支援Oracle Primary + Standby的DataGuard架構的部署，支援MySQL Master + Slave主從複製讀寫分離架構的部署，支援資料路由中介軟體 + Sharding架構的部署，支援MGC/PXC/MGR強同步叢集的部署，同時在部署方式上，既相容計算、儲存分離又相容本地儲存方式。

那麼問題來了，任何一個Node、容器、Instance發生故障，都會不同程度上影響業務的連續性。這是沃趣科技資料庫專家、Kubernetes與容器技術專家、開發專家需要通力合作去攻關的，讓客戶用上最好的資料庫技術，是我們不懈的追求。

下圖是計算、儲存分離架構中，Kubernetes結合沃趣科技QCFS分散式儲存實現的資料庫例項快速failover的技術實現。

將有狀態的資料下沉到儲存層，Node故障Scheduler重新排程容器時，無需感知計算節點的儲存介質，只需排程到滿足計算資源要求的 Node，資料庫例項啟動時，只需在分散式檔案系統掛載相應的 volume 即可。

分散式儲存自帶資料多副本冗餘特性，但是在MGC/PXC/MGR架構中，資料庫叢集層已經解決了資料的多副本存放，所以，在這種情況下，使用分散式儲存看起來並不是一個高效、經濟的方案。從使用者的角度出發，在這種架構中，我們認為本地儲存是更優的方案，但當Node發生故障時，意味著我們要做更多的工作。這種種複雜場景，都是沃趣作為專業資料庫產品服務廠商要下決心幫使用者搞定的。

｜資料持久安全

當今經濟社會，資料發揮著越來越大的重要性，企業依託資料本身，提供形形色色的服務，不僅如此，對資料的挖掘亦能創造未來價值。資料的重要性不言而喻，如何保證資料的安全可靠，企業對資料備份提出了越來越高的要求。

QFusion 3.0作為涵蓋資料庫全生命週期的RDS雲平臺，資料的備份與安全存放是產品設計考慮的重要一環，涵蓋資料庫的定時備份，備份有效性校驗及資料恢復服務。

｜監控管理

不多說，直接上圖。 

QFusion 3.0 RDS雲平臺高度的產品化將資料庫全生命週期管理工作全部以web形式呈現給使用者，輕鬆速學易上手，極大解放DBA的生產力。

｜小結

Kelsey Hightower是Google的Kubernetes佈道師，曾經有不建議將database執行在Kubernetes上的言論。但沃趣科技投入了大量的人力、精力進行資料庫容器化的落地工作，資料庫專家、Kubernetes與容器技術專家、開發專家通力合作，不僅完成了技術難點的攻克，並以此為基礎完成了QFusion 3.0 RDS全生命週期管理雲平臺的高度產品化。

可喜的是，在2月28日，雲原生應用計算基金會 (Cloud Native Computing Foundation，以下簡稱CNCF) 宣佈沃趣科技私有云RDS平臺QFusion正式通過 “Kubernetes軟體一致性認證”。

沃趣科技將持續回饋社群，積極參與CNCF組織的技術分享，並通過技術文章，給業界傳播基於雲原生架構的私有云RDS平臺價值。未來，沃趣科技還將給社群貢獻關於MySQL、Oracle各種叢集架構的Docker Image，這些正是目前社群所緊缺的資源。

｜作者簡介

郭旭瑞·沃趣科技產品專家

熟悉Oracle資料庫內部機制，豐富的資料庫及RAC叢集層故障診斷、效能調優、OWI、資料庫備份恢復及遷移經驗。歷任沃趣科技高階資料庫工程師，負責華夏銀行、華泰證券、中信證券、浙江電力、浙江移動等金融及企業級客戶的資料庫產品、架構實施方案、容災方案、遷移方案設計及服務工作；任產品服務交付部門負責人，帶領專案交付團隊完成公司產品及服務交付職能；任資料庫架構專家，負責私有云RDS等產品的資料庫架構設計、技術預研及落地工作。