經(jīng)過這些年企業(yè)IT上云，云平臺已經(jīng)成為了企業(yè)最關(guān)鍵的IT基礎(chǔ)設(shè)施了。很多企業(yè)甚至全面學(xué)習(xí)互聯(lián)網(wǎng)企業(yè)的經(jīng)驗，通過云平臺將應(yīng)用架構(gòu)做了徹底的云化，通過領(lǐng)域建模等將數(shù)據(jù)庫也拆分為規(guī)模很小，數(shù)量龐大的領(lǐng)域數(shù)據(jù)庫了，這些數(shù)據(jù)庫規(guī)模不大，大部分可以使用云上的RDS服務(wù)。這種轉(zhuǎn)型讓企業(yè)的IT基礎(chǔ)設(shè)施與IT運維變得十分扁平化，也變得很簡單。不過大量的傳統(tǒng)行業(yè)企業(yè)的應(yīng)用系統(tǒng)還無法與互聯(lián)網(wǎng)企業(yè)一樣，數(shù)據(jù)庫依然是IT系統(tǒng)里比較重的組件。這些企業(yè)大多存在數(shù)據(jù)庫上云的需求，只不過因為技術(shù)原因，目前還不敢把未能小型化的數(shù)據(jù)庫完全遷移到云上。

將數(shù)據(jù)庫這個“重”IT組件也上云管理，是很多傳統(tǒng)企業(yè)用戶近些年在努力做的事情，也有一些企業(yè)已經(jīng)把一些“重”數(shù)據(jù)庫遷移上云，不過上云后的效果不盡如人意。

(資料圖片)

他們在把一些商用數(shù)據(jù)庫遷移到云上的時候，遇到了很多問題。首先必然會遇到的一個問題是云平臺對商用數(shù)據(jù)庫原本是不支持的，而且因為商業(yè)競爭的問題，哪怕是企業(yè)內(nèi)部部署的私有云，云平臺供應(yīng)商都不大愿意納管競品商用數(shù)據(jù)庫產(chǎn)品。商用數(shù)據(jù)庫上云往往只能憋屈地使用云平臺上的ECS，在上面進(jìn)行手工部署。哪怕通過自定義鏡像快速部署編排好數(shù)據(jù)庫實例的ECS，在使用的時候也受到種種限制。比如云盤的性能不穩(wěn)定導(dǎo)致數(shù)據(jù)庫運行不穩(wěn)定；底層虛擬機(jī)的IO優(yōu)化沒有考慮數(shù)據(jù)庫的場景導(dǎo)致數(shù)據(jù)庫丟失IO出現(xiàn)壞塊；云盤容量受限導(dǎo)致數(shù)據(jù)庫出現(xiàn)存儲空間不足；數(shù)據(jù)庫備份受限于網(wǎng)絡(luò)帶寬不足而無法在維護(hù)窗口完成備份，等等等等。

前些年也有很多企業(yè)和我交流過這個問題，不過這些年少了不少，很多企業(yè)都繞道走了。前陣子和一個金融企業(yè)交流云上的國產(chǎn)數(shù)據(jù)庫的性能問題的時候，我問他們這么做的目的是什么。他們覺得以后用了國產(chǎn)或者開源數(shù)據(jù)庫，數(shù)據(jù)庫實例的數(shù)量會翻倍，不讓IT盡可能扁平化，今后將面臨更大的挑戰(zhàn)。從這個角度上看在未來較大型的數(shù)據(jù)庫上云依然是很多企業(yè)無法避免的事情。

實際上讓公有云或者私有云支持國產(chǎn)商用數(shù)據(jù)庫是沒有任何問題的，數(shù)年前阿里云推出的云速搭CADT，可以通過復(fù)雜的模板支持針對Oracle RAC在內(nèi)的復(fù)雜應(yīng)用系統(tǒng)的編排。從阿里云實現(xiàn)對Oracle RAC的支持，我們也可以學(xué)習(xí)到很多大型數(shù)據(jù)庫系統(tǒng)上云的一些思路。支撐阿里云支持Oracle RAC的組件包括：

l轉(zhuǎn)發(fā)路由器 TR（Transit Router）：提供連接網(wǎng)絡(luò)實例、自定義路由表、添加路由條目、添加路由策略等豐富的網(wǎng)絡(luò)互通和路由管理功能；該功能可以與CEN結(jié)合，實現(xiàn)Oracle RAC的INTERCONNECT 多播網(wǎng)絡(luò)；

在云平臺上以接近云原生的方式實現(xiàn)一個大型Oracle RAC的編排還是有點費勁的，哪怕是把Oracle RAC搭建好，并能夠承受高負(fù)載都不是一件很容易的事情。在云納管大型關(guān)鍵數(shù)據(jù)庫的時候，一般會采用裸金屬服務(wù)器或者虛擬化云主機(jī)兩種模式。如何對這兩種部署模式進(jìn)行標(biāo)準(zhǔn)化設(shè)計并針對大型關(guān)系型數(shù)據(jù)庫進(jìn)行優(yōu)化，其實是要事先考慮好的。阿里云的這個方案可以給我們一些啟示-網(wǎng)絡(luò)和存儲是其中最為關(guān)鍵的因素。

存儲方面，阿里可以提供高性能低延時的ESSD塊存儲。在我們自己的云環(huán)境里，也可以購買一些商用的高性能分布式存儲來構(gòu)建存儲資源池，專用于大型數(shù)據(jù)庫存放數(shù)據(jù)。這些存儲在優(yōu)化上必須滿足塊存儲的所有特征，能夠支持通用負(fù)載，這樣才能盡可能避免分布式存儲底層的不兼容而導(dǎo)致數(shù)據(jù)庫丟失IO，出現(xiàn)壞塊，引發(fā)數(shù)據(jù)安全的故障。在云主機(jī)的物理機(jī)上直接連接集中式存儲用于存儲數(shù)據(jù)庫的文件也是一種在云平臺技術(shù)無法滿足大型關(guān)系型數(shù)據(jù)庫需求時的一種常見做法，當(dāng)年在數(shù)據(jù)庫遷移到VMWARE資源池的時候已經(jīng)有不少企業(yè)試用過這個方法，效果還不錯。無論使用哪種方法，確保IO的可靠性和穩(wěn)定性是關(guān)鍵。IO不能丟失，IO延時必須穩(wěn)定，并且最好不高于20毫秒，是云平臺必須為大型數(shù)據(jù)庫上云提供的保證。

另外一個方面是網(wǎng)絡(luò)，對于集中式數(shù)據(jù)庫還好，網(wǎng)絡(luò)問題不突出。對于Oracle RAC這樣對于集群網(wǎng)絡(luò)性能和可靠性要求十分高的場景，網(wǎng)絡(luò)要求就很高了。另外分布式數(shù)據(jù)庫對于集群網(wǎng)絡(luò)的性能與延時也是十分敏感的，必須為集群網(wǎng)絡(luò)提供高帶寬，低延時的虛擬網(wǎng)絡(luò)支持。實際上普通的大型數(shù)據(jù)庫對于網(wǎng)絡(luò)也有較高的要求，存儲網(wǎng)絡(luò)（使用IPSAN的場景）、備份網(wǎng)絡(luò)的帶寬和延時決定了數(shù)據(jù)庫是否有足夠的性能和易于運維管理。

除此之外，數(shù)據(jù)庫的前端連著應(yīng)用，后端連著數(shù)據(jù)中臺，還和其他云上云下的業(yè)務(wù)系統(tǒng)保持著復(fù)雜的關(guān)系，因此對于云上的轉(zhuǎn)發(fā)路由器TR也有十分高的要求。而高可用切換、雙活等需求又要求VIP能夠很方便的漂移。虛擬大二層網(wǎng)絡(luò)的能力決定了雙活是否能跨機(jī)房甚至跨數(shù)據(jù)中心，這些都是要考慮的。阿里云的VPC、CEN-TR解決了這方面的后顧之憂。

對于分布式數(shù)據(jù)庫，還有一個麻煩的事情，那就是云存儲的多副本與分布式數(shù)據(jù)庫的多副本之間的多重副本機(jī)制帶來的問題。很多企業(yè)的分布式數(shù)據(jù)庫在云上是跑在云存儲上的，二者的副本機(jī)制會產(chǎn)生很高的疊加效應(yīng)，既浪費了存儲資源，又影響了數(shù)據(jù)庫的性能。較為大型的高負(fù)載的分布式數(shù)據(jù)庫在云上部署最好采用裸金屬部署的模式，如果必須使用云主機(jī)，可以考慮使用集中式存儲或者使用單副本的云存儲。

標(biāo)簽：