摘 要:企業(yè)信息化實現(xiàn)所必須依賴的關系型數(shù)據(jù)庫是基于共享存儲或者熱備的方式來實現(xiàn)高可用的。在高可用的實現(xiàn)過程中存在用戶需求不明確和硬件投資成本太高的問題,企業(yè)對高可用方案的可管理性與系統(tǒng)復雜性之間的矛盾。基于SLA的數(shù)據(jù)庫高可用方案將SLA與數(shù)據(jù)庫可靠性有機的結合在一起,有效的解決了數(shù)據(jù)庫高可用在實施過程中的投資和收益矛盾。
關鍵詞:SLA;數(shù)據(jù)庫;高可用性;服務質量
中圖分類號:TP311.131 文獻標識碼:A
Abstract:The relational database,which enterprise informatization depends on,achieves high availability based on shared storage or hot standby.Many problems are encountered in the implementation process of database high availability,such as ambiguous user requirements,high hardware investment cost,and the contradiction between the manageability of the high availability scheme and the complexity of the system.According to the SLA-based database high availability scheme,the paper organically combines SLA with the database reliability,which effectively solves the contradiction between investment and profit during the implementation process of database high-availability.
Keywords:SLA;database;high availability;service quality
1 引言(Introduction)
數(shù)據(jù)庫已經(jīng)成為企業(yè)信息化和數(shù)字化不可或缺的核心數(shù)據(jù)管理系統(tǒng)。數(shù)據(jù)是企業(yè)最為核心的無形資產,提供高可用的數(shù)據(jù)庫服務是數(shù)據(jù)庫管理系統(tǒng)的核心目標。為了實現(xiàn)數(shù)據(jù)庫高可用的目標往往需要付出昂貴的服務和設備費用,但是在出現(xiàn)數(shù)據(jù)庫相關故障時仍舊難以應付,在相應的時間內完成數(shù)據(jù)庫的恢復,繼而繼續(xù)提供生產服務[1,2]。服務等級協(xié)議(SLA)被廣泛應用與描述服務所需要達到的性能目標,能夠將企業(yè)對數(shù)據(jù)庫高可用的需求與高可用實現(xiàn)的目標有機的關聯(lián)起來。SLA可以幫助用戶梳理對數(shù)據(jù)庫可用性的等級需求,對應等級需求實現(xiàn)的可用性方案,并且通過SLA也可以明確用戶對數(shù)據(jù)損失和恢復生產時間的需求,進一步理解數(shù)據(jù)庫可靠性的含義。
2 數(shù)據(jù)庫高可用方案(High availability scheme of
database)
近年來,互聯(lián)網(wǎng)通過云計算的方式將高昂的設備費用轉化給計算能力提供給用戶,以MySQL、OceanBase、Mango等分布式數(shù)據(jù)庫,通過軟件實現(xiàn)自動容錯,使得自身故障對外部使用者不可見,能夠將數(shù)據(jù)庫部署在廉價的不可靠低端服務器上,且能夠同時滿足高可用與強一致性[3]。但是數(shù)據(jù)作為企業(yè)的核心資產,尤其對部分企業(yè)來說出于對安全保密的考慮,難以將企業(yè)的數(shù)據(jù)部署到公有云數(shù)據(jù)庫中。
本文以Oracle DB作為企業(yè)主流數(shù)據(jù)庫來研究數(shù)據(jù)庫高可用方案,Oracle DB實現(xiàn)高可用的方案主要有RAC高可用集群、DataGuard熱備和MAA最大可用性架構三種模式[4],其中MAA包含了前兩者的實現(xiàn)。限于篇幅,筆者不再對數(shù)據(jù)庫的常規(guī)備份、恢復機制做研究描述,但是備份、恢復手段亦數(shù)據(jù)庫高可用的基礎。
2.1 RAC高可用集群
Oracle實現(xiàn)高可用的主流方式是通過Oracle自身提供的Cluster集群中間件來搭建集群,在Cluster集群的基礎上構建多臺Oracle主機和實例,并將數(shù)據(jù)存儲在多個實例可以共享訪問的共享存儲中。在每臺服務器中運行著各自的Oracle實例(Node1,Node2,Node3)管理自身的進程和內存、集群ASM實例管理邏輯卷和文件系統(tǒng)、Cluster和Oracle DBMS自身的日志。所有實例都通過HBA卡連接高端的光纖存儲區(qū)域網(wǎng)FC-SAN(Fabre Channel-Storage Area Network)實現(xiàn)共享存儲。共享存儲中需要存儲集群的配置文件、選舉文件、數(shù)據(jù)庫的數(shù)據(jù)文件、在線日志文件、歸檔日志文件和備份文件等。RAC高可用集群的實現(xiàn)方案如圖1所示。
如圖1所示,由于共享在線日志,多服務器組件集群中的任一服務器或者實例出現(xiàn)故障,其他的實例可以迅速接管其故障之前讀寫操作,因此可以繼續(xù)提供服務。相比于單點部署的單實例數(shù)據(jù)庫,RAC集群規(guī)避了單點服務器、實例的故障風險,提高了可靠性[5]。從圖中也可以看出,RAC還提供了橫向擴展能力,能夠為用戶在性能問題上提供解決方案。
雖然RAC集群中ASM卷組考慮了存儲磁盤壞塊的可能性而采用了多路磁盤鏡像提高了存儲磁盤的可用性,但是RAC的整體可用性仍舊受限于共享存儲的可用性。為了保證服務器與存儲之間的可用性,數(shù)據(jù)庫實例和共享存儲之間一般采用光纖存儲交換機或者更高配置的InfiniBand交換機,可以使傳輸速度達到16GB/s—40GB/s,從而保證了實例數(shù)據(jù)的快速讀寫;另外,如果不能采用高端存儲來提供共享存儲,一般需要兩套存儲以同步或者異步的模式完成主備,以規(guī)避因存儲控制器損壞而帶來的存儲單點風險。endprint
2.2 DataGuard熱備
Oracle提供的另一種高可用方案通過DataGuard將主節(jié)點的在線日志復制到熱備節(jié)點實現(xiàn)Master/Slaver,并在熱備節(jié)點應用在線日志的方式實現(xiàn)主備同步。在Master節(jié)點出現(xiàn)故障無法繼續(xù)提供服務的情況下,可以通過自動Failover或者是Switchover手動切換的方式實現(xiàn)快速啟用Slaver節(jié)點(Standby)接手主節(jié)點的服務。DataGuard熱備的實現(xiàn)方案如圖2所示。
DataGuard熱備實現(xiàn)對數(shù)據(jù)庫生產環(huán)境整體備份的高可用機制,按照在線日志在熱備節(jié)點的應用情況可將高可用的保護模式分為最大可用性、最大性能和最大保護三種[6]。
最大可用性模式:Master節(jié)點產生的redo log需要同步至Slaver節(jié)點之后才提交應用。在出現(xiàn)網(wǎng)絡故障時,redo log無法同步至Slaver節(jié)點,最大可用性模式將轉換為最大性能模式。這種模式確保在Master節(jié)點出現(xiàn)故障的時Slaver節(jié)點不會丟失太多數(shù)據(jù),最多丟失Master節(jié)點出現(xiàn)故障時無法傳遞給Slaver的那個redo log。
最大性能模式:Master節(jié)點無需等待redo log同步至Slaver節(jié)點,所以可以保證Master節(jié)點始終能夠保證自身的性能,而不會因為redo log同步的問題導致寫入緩慢。因此,無法保證在Master節(jié)點出現(xiàn)故障時與Slaver節(jié)點的數(shù)據(jù)一致性。
最大保護模式:Master節(jié)點產生的redo log需要同步至Slaver節(jié)點之后才提交應用。出現(xiàn)網(wǎng)絡故障時,Master無法同步redo log至Slaver節(jié)點,而導致Master停止數(shù)據(jù)庫服務,完全保證Master節(jié)點與Slaver節(jié)點的數(shù)據(jù)一致性。因此,因網(wǎng)絡因素、Slaver服務器因素等難以確保架構的高可用。
2.3 MAA架構
MAA(Maximum Availability Architecture)最大可用性架構是通過結合RAC與DataGuard實現(xiàn)的高可用方案,按照圖3的方式MAA架構由兩套三節(jié)點RAC集群通過Data Guard實現(xiàn)。在RAC1中可容忍服務器、操作系統(tǒng)和數(shù)據(jù)庫實例級別的單節(jié)點故障,對于MAA整體架構來說可以繼續(xù)容忍RAC1存儲、區(qū)域網(wǎng)絡級別的故障,通過Failover或者手動Switchover將生產服務轉移至RAC2繼續(xù)提供。
總之,在用戶了解其數(shù)據(jù)核心價值之后,需要慎重選擇數(shù)據(jù)庫高可用的方案。因為,每一種方案都對應了能夠為用戶的帶來的不同等級的高可用實現(xiàn)能力、每一種方案的背后都是企業(yè)軟硬件固定資產的投資、每一種方案都需要不同等級的DBA來綜合管理。為了能夠清晰的梳理用戶需求,讓用戶切實的認識高可用方案的投資與價值,筆者研究了服務等級協(xié)議在數(shù)據(jù)庫高可用方案中的應用。
3 基于SLA數(shù)據(jù)庫高可用需求(High availability for
the database based on SLA)
服務等級協(xié)議(Service Level Agreement,SLA)是由ITTF提出,用于約定服務質量指標和服務雙方責任的正式協(xié)議,SLA是服務提供商和用戶之間為了保證服務質量而簽署的一份關于服務內容、雙方的責任和義務、質量等級與價格的服務細節(jié)的協(xié)議[7]。通過將SLA應用于數(shù)據(jù)庫高可用實現(xiàn),能夠明確企業(yè)需求與高可用服務質量的定義,將有差異的個性化服務與不同的實際需求相結合。筆者研究了數(shù)據(jù)庫高可用在不同企業(yè)需求影響因素下的實現(xiàn)與企業(yè)需要付出的投資價值,另外還針對不同的高可用方案給出了具體的服務質量目標。
3.1 用戶需求與投資
影響用戶投資于數(shù)據(jù)庫高可用方案和災難恢復解決方案的主要因素是應對不在計劃內數(shù)據(jù)庫停機時間RTO(Recovery Time Objectives or recovery time)和數(shù)據(jù)丟失RPO(Recovery Point Objectives or data loss tolerance)、過度管理(Management Overhead),并考慮高可用系統(tǒng)的總體投資(Total Cost of Ownership)與回報收益(Return on Investment)。
表1概要統(tǒng)計了單實例數(shù)據(jù)庫、數(shù)據(jù)庫RAC集群、數(shù)據(jù)庫DataGuard和最大可用性架構MAA等四種高可用架構的相關參數(shù),單實例數(shù)據(jù)庫在出現(xiàn)故障時需要做介質恢復,因此無法估計RPO和RTO;RAC集群對于單實例故障可以做到無數(shù)據(jù)丟失和無停止服務時間;DataGuard因為Redo log應用的模式不同而會不丟失數(shù)據(jù)或者丟失部分數(shù)據(jù),因為Slaver備機是通過自動Failover或者手動Switchover的方式進行切換,根據(jù)環(huán)境可以在五分鐘內完成切換;由于Oracle MAA是結合了RAC和DataGuard兩種技術,如果是RAC能夠解決的故障,則不會丟失數(shù)據(jù)也不會停止服務,反之,則如同DataGuard。對于管理成本來說,由于單實例數(shù)據(jù)庫出現(xiàn)故障之后需要停止并恢復服務,再次過程中需要針對可用性的管理成本升高;而RAC由于自身多節(jié)點的集群管理,在高可用的管理成本一般;DataGuard作為專業(yè)性熱備,高可用管理成本最低;MAA由于自身結合了RAC和DataGuard兩種技術,高可用管理中必然需要掌握RAC的管理技術,所以高可用管理成本一般。
所以綜合各種高可用方案來看,單實例的投資和匯報較低,RAC和DataGuard的投資成本一般,但是都能提供不同的高可用回報,MAA最大可用性架構投資成本較高,能夠獲得最高的可用性。本文后續(xù)將繼續(xù)分數(shù)據(jù)庫高可用的投資。
對比單實例的Oracle Database,按照不同的節(jié)點數(shù)目需要購置相應數(shù)量的授權。endprint
由于服務器對于任何數(shù)據(jù)庫服務都是必須的,而高可用所需要解決的重點也是軟硬件單點故障而造成的服務不可繼續(xù),所以服務器的投資需要依據(jù)自身的性能要求進行購置,以Oracle MAA為例,MAA既可以RAC環(huán)境同步RAC環(huán)境,也可以實現(xiàn)RAC環(huán)境同步單點環(huán)境;因為共享存儲需要通過光纖交換機連接存儲,所以光纖交換機是否需要實現(xiàn)主備模式而提高光纖網(wǎng)絡的高可用需要企業(yè)依據(jù)自身對網(wǎng)絡的要求進行配置;因為共享存儲是RAC實現(xiàn)高可用的單點受限因素,所以企業(yè)需要在存儲采購過程中清楚存儲的可靠性,并考慮實現(xiàn)存儲級別的高可用。
在軟硬件的配置之外,企業(yè)還需要依據(jù)需求配置數(shù)據(jù)庫管理人員,表2中體現(xiàn)了數(shù)據(jù)庫管理的最低配置而非絕對配置。
3.2 服務質量目標
在企業(yè)明確對數(shù)據(jù)庫高可用的需求之后,不同的高可用方案可實現(xiàn)不同的質量目標,而對于數(shù)據(jù)庫高可用來說關鍵的指標是RPO和RTO,筆者分別針對不同故障予以說明[6]。
在生產環(huán)境中出現(xiàn)數(shù)據(jù)庫故障之后,因為數(shù)據(jù)庫高可用的架構不同,可能會丟失部分數(shù)據(jù),本文主要列舉了單實例故障、服務器故障、存儲故障、用戶錯誤和數(shù)據(jù)損壞等數(shù)據(jù)丟失情況,配合常規(guī)數(shù)據(jù)庫RMAN備份手段,Oracle MAA只有在存儲整體損壞不可用(不是磁盤級損壞)會因為DataGuard應用日志為選擇最大保護模式而會丟失部分數(shù)據(jù)(文中所提到“部分數(shù)據(jù)”都指因網(wǎng)絡等因素導致Master所產生的redo log 未能同步至Slaver節(jié)點而導致丟失部分數(shù)據(jù))。DataGuard最為專業(yè)的熱備,與MAA能夠提供同樣級別的數(shù)據(jù)損失保護能力。RAC由于存在存儲單點故障的風險,因此可能會丟失備份后的歸檔日志。
在生產環(huán)境中可能存在多種DBA需要應對的數(shù)據(jù)庫故障,筆者主要針對由于硬件服務器故障、網(wǎng)絡故障、操作系統(tǒng)升級和數(shù)據(jù)庫升級等場景,研究高可用架構的大約停機時間(具體的停機時間跟DBA管理能力、故障的復雜程度、規(guī)章制度的明細等正相關,本文不詳細闡述)。在表4中列舉的故障情況也存在多樣性,以單點網(wǎng)絡故障為例,表中研究的是數(shù)據(jù)庫對外提供服務的網(wǎng)絡出現(xiàn)了故障中斷,而不是RAC自身心跳通訊故障中斷或者DataGuard同步網(wǎng)絡中斷。具體的情況需要在SA中詳細分裂描述,而不能以一概全。
由于MAA具備RAC和DataGuard的技術,只有在多點網(wǎng)絡故障、多節(jié)點服務器故障和存儲故障影響了RAC不可用的情況下需要通過Failover或者Switchover的切換至備機,整個過程可以控制在兩分鐘內,其他情況下可以通過輪詢的方式進行處理,幾乎不影響生產服務。DataGuard在多節(jié)點服務器故障時將無法提供繼續(xù)服務,其他的情況均需要將Slaver切換至Master,可以將時間控制在2分鐘以下。RAC因為存在多節(jié)點服務器,因為在單點網(wǎng)絡故障、服務器故障時不影響生產服務,在操作系統(tǒng)升級、數(shù)據(jù)庫補丁升級等時可采用輪詢的方式,同樣不需要停止服務,但是其他情況下需要分鐘至小時的停機服務用于恢復生產。
4 結論(Conclusion)
本文以Oracle database三種不同的數(shù)據(jù)庫高可用實現(xiàn)機制(RAC、DataGuard和MAA)為研究樣例,說明了數(shù)據(jù)庫高可用實現(xiàn)機制和理論收益的不同。通過將SLA引入數(shù)據(jù)庫高可用方案實現(xiàn)中,本文概要研究了企業(yè)需求、投資、RTO和RPO。研究表明,SLA可以讓企業(yè)更加明確自身對數(shù)據(jù)庫高可用的需求、全面而深入的了解數(shù)據(jù)庫高可用實現(xiàn)的不同機制、不同數(shù)據(jù)庫高可用方案能夠達到的效果,以及需要實現(xiàn)數(shù)據(jù)庫高可用而付出的不同投資。有效的解決了企業(yè)在數(shù)據(jù)庫高可用實施過程中需求、投資、期望和收益等環(huán)節(jié)的各項問題。
參考文獻(References)
[1] 何花.高可用技術在數(shù)據(jù)庫領域中的應用[A].2016智能城市與信息化建設國際學術交流研討會論文集IV,2016.
[2] 周春華.系統(tǒng)數(shù)據(jù)庫可靠性分析[J].電子產品可靠性與環(huán)境試驗,2016,34(01):48-51.
[3] 楊傳輝.OceanBase高可用方案[J].華東師范大學學報:自然科學版2014,9(5):173-179.
[4] Oracle.MAA[EB/OL].http://www.oracle.com/goto/maa.
[5] Oracle.RAC[EB/OL].http://docs.oracle.com/cd/E11882_01/rac.112/e41960/toc.htm.
[6] Oracle.DataGuard[EB/OL].http://docs.oracle.com/cd/E11882_01/server.112/e41134/toc.htm.
[7] 趙又霖.基于服務等級協(xié)議的云服務成本計算模型研究[D].武漢:武漢大學,2014.
作者簡介:
張慶民(1969-),男,碩士,研究員.研究領域:系統(tǒng)集成,信息安全.endprint