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

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

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

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

實際上讓公有云或者私有云支持國產商用數據庫是沒有任何問題的，數年前阿里云推出的云速搭CADT，可以通過復雜的模板支持針對Oracle RAC在內的復雜應用系統的編排。從阿里云實現對Oracle RAC的支持，我們也可以學習到很多大型數據庫系統上云的一些思路。支撐阿里云支持Oracle RAC的組件包括：

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

l轉發路由器 TR（Transit Router）：提供連接網絡實例、自定義路由表、添加路由條目、添加路由策略等豐富的網絡互通和路由管理功能；該功能可以與CEN結合，實現Oracle RAC的INTERCONNECT 多播網絡；

• 云速搭 CADT：通過模板實現Oracle rac自動編排。

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

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

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

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

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