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