在云平臺中高可用性數據庫MySQL 的設計與實現?

王素麗

（華南理工大學廣州學院計算機工程學院 廣州 510800）

1 引言

近些年來隨著移動互聯網、物聯網及各種社交軟件的迅猛發展，各種不同環境下產生的數據量獲得了飛速地發展。因此，本人所在的華南理工大學廣州學院計算機學院也通過OpenStack云平臺向社會各界提供數據、信息等多方面的服務。然而，在本人參與搭建的OpenStack 云平臺系統中，通過對系統數據量的長時間分析，發現數據庫在存儲方面的主要壓力來自于以指數級別急速增長的數據存儲量及并發訪問量的急劇增大兩個方面［1］。因此，如何有效地解決這兩方面問題已經成為該Open-Stack云平臺穩定運行的首要問題。

本文主要解決的問題可簡述為當OpenStack云平臺的單節點中MySQL 數據庫由于各種復雜原因而出現問題后導致云平臺無法擴展系統的存儲數據容量，進而導致無法保證對外業務的流暢性及準確性。針對此問題，本文提出了如下解決方案：

1）設計一個MySQL 數據庫集群，使得節點由于各種原因導致出現故障時為了能夠繼續為客戶提供服務而對故障節點實現迅速切換。

2）為了增加云平臺數據存儲的可靠性并提高其擴展性，對數據庫集群的底層數據存儲方面進行修改［2］。該解決方案能夠使得云平臺的存儲節點達到萬級以上，并很容易將數據量的存儲擴展至PB級。

3）為了解決數據庫集群切換時間方面的問題，本文提出了一種優化模型，并針對于該優化模型提出了一種切換算法，從而使得切換時間問題獲得了較為完善的解決。

本人通過多次試驗驗證了上述的解決方案能夠使得云平臺的數據擴展能力得到大幅度地提高，并在單節點出現故障時仍能對客戶提供數據訪問、查詢等諸多服務，同時采用的優化模型還降低了數據庫集群切換時間。

2 基于MySQL 的高可用技術發展現狀及分析

OpenStack 是一個開源的云計算管理平臺項目，其具體工作的實現主要是由幾個重要組件協作來完成的，而這些組件都是在MySQL 數據庫的基礎上才能運行的。通過論文檢索，本人將MySQL數據庫在國內外的高可用技術方面總結為下面幾種。

1）MySQL 拷貝技術。該技術采取的方法是將主節點處存儲的數據復制到備用節點處，且備用節點的數目為一個或多個。這樣就能保證當主節點由于某種原因發生故障時備用節點仍然能夠繼續為客戶提供數據查詢等方面的服務［3］。該技術又有同步和異步兩種不同的復制方法，但是二者在實際實現時又存在著各自的不足：前者實現時會在增加節點的同時使得鎖競爭現象大量的出現并極易導致死鎖情況發生，進而使得系統的響應時間驟增；后者在實現過程中雖然不會出現節點增加、死鎖等情況的發生，但是由于采用異步復制的方法，節點間數據不同的情況時有發生。

2）MySQL Cluster 集群技術。該技術是MySQL官方很早以前推出了一種分布式的多主機架構的集群技術，主要由存儲、SQL 及管理三種不同的組件構成，三者的硬盤及內存等硬件設備均為獨立的，不會出現單點在運行過程中的發生故障的情況［4］。而且，在數據存儲方面采用NDB這種全新的數據存儲方式來保存節點處的數據。同時，為了保證數據復制過程中的一致性，該技術還在同步復制的兩個階段都采用了協議提交的方法。但是，該技術的維護成本要遠高于其它高可用技術，且其配置過程過于復雜，因此，其在實際工作環境中很難得到推廣。

3）DRBD 技術。該技術使用內核模塊的方法來實現MySQL 數據庫的數據同步復制，同時由于該技術是由相關腳本及內核模塊組成的，所以其可以構建出高可用性的集群，這一技術特點較容易實現高可用性的MySQL數據庫［5］。但是，該技術由于極易造成資源浪費、存儲方式等原因使得其在實際應用中受到很大的限制。

3 基于MySQL的高可用性設計方法

基于上述問題的分析，本人在設計中對于節點的創建主要是通過紅帽的附加組件并通過集群的形式向客戶提供服務，而數據存儲方面主要是通過Ceph 文件系統來實現的。在集群建成以后，在故障切換方面我們可以使用集群中的組件來完成，也就是說即使集群中的N 個節點由于各種原因而同時出現故障時，只要有一個節點處于正常運行狀態，整個集群的運行仍是正常的，還能夠為客戶提供各種數據服務，進而真正體現了MySQL 數據庫的高可用性［6］。其整體結構示意圖如圖1所示。

圖1 集群整體框架圖

3.1 Ceph文件系統簡介

在分布式文件系統中，Ceph 以其規模大、可靠性高、擴展性強等諸多優點而著稱。其架構主要由元數據服務器、集群監控、客戶端、集群四部分組成，結構示意圖如圖2所示。

從上圖可知，Ceph 系統可以通過客戶端與集群監控或者集群進行互訪而獲得整個集群的映射圖。同時，為了對數據進行各種操作，必須獲取數據的存儲位置，Ceph系統對于這一問題是通過Map圖并結合CRUSH 算法而實現的。Ceph 系統的元數據服務器采用POSIX 標準，能夠執行諸如cp、ls等指令。該服務器的主要功能是將文件名映射為元數據，這是由于其內部能夠對索引節點進行管理，從而將文件名轉換為索引節點，文件I/O所使用的數據也是由其轉換而來的［7］。系統中的集群主要功能之一是完成數據的存儲、復制、回填等事宜，并能監測其它集群的運行情況，當出現運行異常時能夠向集群監控發出警報并提交監測報告。從其功能上可以看出，該系統的OSD集群智能化程度較高，因此，其擁有獨立的CPU、存儲系統、網絡等硬件設施。Ceph 系統的集群監控主要功能為集群映射、CRUSH映射等方面的監控。

圖2 Ceph集群的理論架構圖

圖3 集群高可用性架構圖

3.2 系統的附加組件概述

系統在集群方面的設計時采用的是x86 系統的普通服務器通過附加組件連接而成的，并在此基礎上使用MySQL 數據庫及其它資源共同組成系統資源，以此為客戶提供各種服務。在整個系統架構中，組件的主要功能為節點出現故障時實現切換、數據管理、節點監控等諸多功能，其結構示意圖如圖3所示。

由上述示意圖可知，整個系統的集群結構可以分為如下幾部分。

1）集群管理組件。該組件的主要功能是對集群進行多方面的管理，并對集群間的交互進行仲裁。當集群中的節點發生故障而導致數據傳輸出現問題時，該組件能夠向其它組件發出信息，使得其它組件能夠采取相應的動作以保證數據的正常化運行。在仲裁方面，如果集群中的活躍節點的數目大于半數時，該組件就能保證集群的仲裁功能，反之則不行，組件此時就會停止集群的各種活動，以使得集群不會發生“腦裂”［8］。

2）鎖管理組件。該組件位于集群中的各個節點內，其提供了一種有效地訪問機制，該機制能夠高效地管理集群中的其它組件與共享資源的數據交互。共享資源中的全局文件系統（GFS2）和集群邏輯卷（CLVM）都是通過該組件來實現數據同步及卷組更新的。

3）保護組件。該組件的主要功能是隔離集群中出現故障的節點，使得數據交互過程中的完整性能夠得到保證。同時，該組件所使用的保護策略是在系統設計過程中配置的。當集群管理組件發現集群中的某一節點出現故障時，將立即向保護組件發送信息，保護組件根據發送信息的內容將對應的故障節點進行隔離［9］。在保護組件對故障節點進行隔離時，共享資源將停止正在進行的所有線程，當隔離完成后，線程將會得到恢復。

4）高可用服務管理器。該管理器提供了一種對集群服務的管理能力，當一個節點的服務失敗時，其可以將服務從這個故障節點轉移到集群中其它正常節點上來，從而保證了交互數據的完整性。故障切換服務是自動、透明的，切換到的正常節點的優先級既可以由用戶自身決定，也可以由系統隨機決定。

5）全局文件系統。該文件系統是由RedHat 在GFS1 文件系統的基礎上加以完善而得到的，其改進之處主要體現在如下幾方面：集群中的多個節點可以同一時刻與共享資源中的某些文件系統進行交互；在與Linux 內核進行數據交互時，GFS2 可以直接作為普通的文件系統來實現；在優化集群方面，該文件系統使用多個日志來實現［10］。

4 系統的架構設計及優化

當集群中出現故障節點時，如何盡快地恢復數據傳輸業務將是衡量系統性能的重要指標。但是，集群中的各個節點由于硬件設備、分布距離、運行環境等原因而使得故障切換時間大不相同。為了解決這一問題，我們在對系統的架構進行優化時，對節點性能采用動態的方式進行排序，并將此結果作為節點切換的參考標準。因此，對系統的優化分為節點負載的計算、最優節點的選擇、優先級的調整等三部分。其流程示意圖如圖4所示。

1）節點負載的計算。為了獲得集群中節點的負載情況，每個節點在運行時都會同時使用一些程序獲得本節點的內存使用率、中央處理器的使用率及數據傳輸方面的信息，并將這些信息帶入下面的式（1）以計算出節點的負載值，并將此值傳遞給控制端。

2）最優節點的選擇

如1）所述，當節點將自身的負載發送給控制端后，控制端將通過如下的算法來獲取最優節點，該算法如下所示。

3）優先級的調整

利用2）中的算法將節點進行排序后組成集合M，所謂的動態方式指的是當集合M 中節點的優先級沒有發生變化的時候，配置文件將不會被改寫，反之，系統則會使用附加組件將M中的排序值寫入配置文件，并將此配置文件發送到集群中的各個節點，使得節點中的配置文件得到同步更新，并將更新成功的信息返回。

5 系統實驗及結果分析

系統實驗環境的搭建由以下幾部分組成：

1）分布式系統：一臺客戶端節點；一臺監控節點；六臺OSD 節點，未配置元數據服務器。Ceph 系統采用的是2015年八月份發行的0.94.4版本，并對集群進行了手動配置，配置的具體環境如表1 所示。

為了體現集群的高性能性和可靠的安全性，我們將集群分為兩個網絡：

表1 Ceph的集群配置

（1）公共網絡：該網絡的主要功能是OSD 節點與客戶端節點進行數據交互；

（2）集群網絡：該網絡的主要功能是OSD 節點間的數據交互及節點監測。

2）節點服務器采用的是紅帽公司的RHEL 6.5操作系統；

3）數據庫采用的是MySQL數據庫的5.7.13版。

在完成對數據庫的配置工作后，我們還需要在各個節點中安裝紅帽公司的rgmanager 、lvm2-cluster 、gfs2-utils 三個附加組件。為了能夠對這些附加組件進行管理和配置，我們需要對集群管理節點中的文件(/etc/cluster/cluster.conf)進行創建，文件中對集群的屬性，包括隔離策略、故障節點ID、集群名稱、故障保護資源等通過XML 語言進行描述。在集群管理節點對配置文件完成自定義后，必須將該文件同步到集群中的各個節點。在完成整個集群架構的建設后，我們還需要創建出一個塊設備并將其映射到客戶端節點，塊設備的大小由用戶自行設置。同時，MySQL節點也需要該塊設備的數據，我們主要使用ISCSI 協議來完成塊設備與節點映射的。隨后，我們要完成磁盤的分區并將其配置為全局文件系統格式，并在系統的數據存儲路徑中添加該磁盤的路徑。至此我們就完成了整個系統的搭建工作。

圖4 集群優化的流程圖

5.1 系統的擴展性試驗

該項試驗的目的是當集群的存儲空間出現不足時是否能夠在系統不重啟的基礎上通過對分區動態調整的方式來完成存儲空間的擴容。

首先在客戶端使用rbd resize 指令調整rbd 影像的大小；然后將集群中的MySQL 節點再次掛在iscsi target 上；隨后使用clvm 將邏輯卷擴展；最后使用gfs2_grow 指令完成擴容。試驗前后對比如圖5、6所示。

圖5 沒擴容時存儲大小圖

圖6 擴容后存儲大小圖

5.2 系統的故障切換試驗

本項試驗主要用于檢測集群中節點出現故障時系統是否能夠自動完成故障隔離、切換等功能。為了保證試驗的真實性，我們在試驗時令節點1 出現死機，從圖7 所截取的日志不難發現，Fence 設備在收到rgmanager發出的消息后立即對這一消息進行解讀，隨后對節點1 成功的進行了隔離，然后，鎖管理器解除了對節點1 的鎖定。在對配置文件的檢測中發現剩余節點中節點2 的優先級最高，因此，節點2開始提供服務，系統恢復正常狀態。

圖7 故障切換測試圖

圖8 故障切換平均時間優化前后對比圖

5.3 系統的優化性試驗

節點的內存和中央處理器的使用率及數據傳輸方面的參數在上述的負載公式的調節下達到了理論最優化，在這種情況下，我們對此優化模型進行了仿真測試。我們將兩種軟件相結合從而實現了局域網中出現的諸如傳輸延時、數據丟包、時序混亂等較為復雜的網絡情況，第一種為NetEm 模塊，其是建立在Linux 系統內核上的一種網絡模擬模塊，而第二種軟件TC 則屬于高級網絡管理工具iproute2 中的主要組成部分，其能夠調整前者的工作模式、實現流量方面的修正。

在模擬環境配置完成后，我們將系統中的節點數目進行了調整，從最初的三臺調整為試驗中的十一臺，并在調整前后對系統的故障切換時間等參數進行了多次試驗對比，進而驗證了該優化模型的可靠性及安全性，實驗對比結果如圖8、9所示。

圖9 故障切換時間優化前后樣本標準差比較圖

從上面的圖示可以看出，在對系統進行優化后，故障切換時間等參數明顯優于優化前的參數值，從而有力地證明了該優化模型的有效性及可行性。

6 結語

OpenStack 云平臺的組成部分是極為復雜的，而整個OpenStack 平臺的核心部分則為數據庫，這是由于云平臺涉及到的組件都和數據庫有數據交互，如果平臺運行時數據庫方面出現了故障，將會導致整個云平臺的業務出現問題，故障嚴重時還有可能導致平臺的癱瘓。本文就是在此基礎上對MySQL數據庫集群進行了優化，使用了數據庫存儲與對外業務進行分別處理的方式，并在底層開辟了共享資源的文件系統，而在業務層方面，我們使用了Redhat 的附加組件對MySQL 數據庫進行了集群構建，并在集群完成構建后采用了有效的優化算法減少了故障切換方面的參數，最終有力地證明了該系統架構的高可用性及存儲可擴展性。