經(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，在上面進行手工部署。哪怕通過自定義鏡像快速部署編排好數(shù)據(jù)庫實例的ECS，在使用的時候也受到種種限制。比如云盤的性能不穩(wěn)定導(dǎo)致數(shù)據(jù)庫運行不穩(wěn)定；底層虛擬機的IO優(yōu)化沒有考慮數(shù)據(jù)庫的場景導(dǎo)致數(shù)據(jù)庫丟失IO出現(xiàn)壞塊；云盤容量受限導(dǎo)致數(shù)據(jù)庫出現(xiàn)存儲空間不足；數(shù)據(jù)庫備份受限于網(wǎng)絡(luò)帶寬不足而無法在維護窗口完成備份，等等等等。

前些年也有很多企業(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的組件包括：

• HAVIP：High Available Virtual IP Address，簡稱 HAVIP。阿里云虛擬網(wǎng)絡(luò)實現(xiàn)的是基于二層的高可用 IP，通用、簡單、易用。HAVIP 以 secondary ip 的形式存在網(wǎng)卡上，可以有單獨的轉(zhuǎn)發(fā)策略，通過 HAVIP 可以實現(xiàn)浮動 IP，適用于 HA 主備容災(zāi)或者雙活高可用的場景；
• 專有網(wǎng)絡(luò) VPC：基于阿里云創(chuàng)建的自定義私有網(wǎng)絡(luò), 不同的專有網(wǎng)絡(luò)之間二層邏輯隔離，可以在自己創(chuàng)建的專有網(wǎng)絡(luò)內(nèi)創(chuàng)建和管理云產(chǎn)品實例，比如 ECS、負(fù)載均衡、RDS 等。在創(chuàng)建前，您需要結(jié)合具體業(yè)務(wù)，規(guī)劃VPC 和交換機的數(shù)量及網(wǎng)段等；
• 彈性網(wǎng)卡 ENI：彈性網(wǎng)卡 ENI（Elastic Network Interface）是一種可以綁定到專有網(wǎng)絡(luò) VPC 類型 ECS 實例上的虛擬網(wǎng)卡。通過彈性網(wǎng)卡，可以實現(xiàn)高可用集群搭建、低成本故障轉(zhuǎn)移和精細(xì)化的網(wǎng)絡(luò)管理。
• ECS 7 代存儲增強型實例：能夠提供高性能的數(shù)據(jù)庫服務(wù)器，特點是IO延時較低，IOPS較高；
• ESSD 塊存儲：阿里云 ESSD（Enhanced SSD）云盤結(jié)合 25 GE 網(wǎng)絡(luò)和 RDMA技術(shù)，提供單盤高達 100 萬的隨機讀寫能力和單路低時延性能，在此方案中ESSD塊存儲使用的是NVME共享盤作為底層磁盤資源；
• NVME共享盤：支持 NVMe 協(xié)議的 ESSD 云盤被稱為 NVMe 共享盤。NVMe 共享盤支持多 ECS 實例并發(fā)讀寫訪問，具備高可靠、高并發(fā)、高性能等特點。為 ECS實例提供了多實例掛載和 IO 攔截功能。共享盤是為了RAC的多實例并發(fā)讀寫共享存儲；
• 云企業(yè)網(wǎng) CEN：云企業(yè)網(wǎng)（Cloud Enterprise Network，簡稱 CEN）是阿里云提供的一款能夠快速構(gòu)建混合云和分布式業(yè)務(wù)系統(tǒng)的全球網(wǎng)絡(luò)服務(wù)，為用戶提供優(yōu)質(zhì)、高效、穩(wěn)定的網(wǎng)絡(luò)傳輸環(huán)境，幫助用戶打造一張具有企業(yè)級規(guī)模和通信能力的云上網(wǎng)絡(luò)。適用于集團企業(yè)、全球網(wǎng)絡(luò)等場景；

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

• 云速搭 CADT：通過模板實現(xiàn)Oracle rac自動編排。

在云平臺上以接近云原生的方式實現(xiàn)一個大型Oracle RAC的編排還是有點費勁的，哪怕是把Oracle RAC搭建好，并能夠承受高負(fù)載都不是一件很容易的事情。在云納管大型關(guān)鍵數(shù)據(jù)庫的時候，一般會采用裸金屬服務(wù)器或者虛擬化云主機兩種模式。如何對這兩種部署模式進行標(biāo)準(zhǔn)化設(shè)計并針對大型關(guān)系型數(shù)據(jù)庫進行優(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ù)安全的故障。在云主機的物理機上直接連接集中式存儲用于存儲數(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ò)的能力決定了雙活是否能跨機房甚至跨數(shù)據(jù)中心，這些都是要考慮的。阿里云的VPC、CEN-TR解決了這方面的后顧之憂。

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