本文來自微信公眾號“白鱔的洞穴”，作者/白鱔。
經(jīng)過這些年企業(yè)IT上云，云平臺已經(jīng)成為了企業(yè)最關(guān)鍵的IT基礎設施了。很多企業(yè)甚至全面學習互聯(lián)網(wǎng)企業(yè)的經(jīng)驗，通過云平臺將應用架構(gòu)做了徹底的云化，通過領(lǐng)域建模等將數(shù)據(jù)庫也拆分為規(guī)模很小，數(shù)量龐大的領(lǐng)域數(shù)據(jù)庫了，這些數(shù)據(jù)庫規(guī)模不大，大部分可以使用云上的RDS服務。這種轉(zhuǎn)型讓企業(yè)的IT基礎設施與IT運維變得十分扁平化，也變得很簡單。不過大量的傳統(tǒng)行業(yè)企業(yè)的應用系統(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)部部署的私有云，云平臺供應商都不大愿意納管競品商用數(shù)據(jù)庫產(chǎn)品。商用數(shù)據(jù)庫上云往往只能憋屈地使用云平臺上的ECS，在上面進行手工部署。哪怕通過自定義鏡像快速部署編排好數(shù)據(jù)庫實例的ECS，在使用的時候也受到種種限制。比如云盤的性能不穩(wěn)定導致數(shù)據(jù)庫運行不穩(wěn)定；底層虛擬機的IO優(yōu)化沒有考慮數(shù)據(jù)庫的場景導致數(shù)據(jù)庫丟失IO出現(xiàn)壞塊；云盤容量受限導致數(shù)據(jù)庫出現(xiàn)存儲空間不足；數(shù)據(jù)庫備份受限于網(wǎng)絡帶寬不足而無法在維護窗口完成備份，等等等等。
前些年也有很多企業(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，可以通過復雜的模板支持針對Oracle RAC在內(nèi)的復雜應用系統(tǒng)的編排。從阿里云實現(xiàn)對Oracle RAC的支持，我們也可以學習到很多大型數(shù)據(jù)庫系統(tǒng)上云的一些思路。支撐阿里云支持Oracle RAC的組件包括：
lHAVIP：High Available Virtual IP Address，簡稱HAVIP。阿里云虛擬網(wǎng)絡實現(xiàn)的是基于二層的高可用IP，通用、簡單、易用。HAVIP以secondary ip的形式存在網(wǎng)卡上，可以有單獨的轉(zhuǎn)發(fā)策略，通過HAVIP可以實現(xiàn)浮動IP，適用于HA主備容災或者雙活高可用的場景；
l專有網(wǎng)絡VPC：基于阿里云創(chuàng)建的自定義私有網(wǎng)絡,不同的專有網(wǎng)絡之間二層邏輯隔離，可以在自己創(chuàng)建的專有網(wǎng)絡內(nèi)創(chuàng)建和管理云產(chǎn)品實例，比如ECS、負載均衡、RDS等。在創(chuàng)建前，您需要結(jié)合具體業(yè)務，規(guī)劃VPC和交換機的數(shù)量及網(wǎng)段等；
l彈性網(wǎng)卡ENI：彈性網(wǎng)卡ENI（Elastic Network Interface）是一種可以綁定到專有網(wǎng)絡VPC類型ECS實例上的虛擬網(wǎng)卡。通過彈性網(wǎng)卡，可以實現(xiàn)高可用集群搭建、低成本故障轉(zhuǎn)移和精細化的網(wǎng)絡管理。
lECS 7代存儲增強型實例：能夠提供高性能的數(shù)據(jù)庫服務器，特點是IO延時較低，IOPS較高；
lESSD塊存儲：阿里云ESSD（Enhanced SSD）云盤結(jié)合25 GE網(wǎng)絡和RDMA技術(shù)，提供單盤高達100萬的隨機讀寫能力和單路低時延性能，在此方案中ESSD塊存儲使用的是NVME共享盤作為底層磁盤資源；
lNVME共享盤：支持NVMe協(xié)議的ESSD云盤被稱為NVMe共享盤。NVMe共享盤支持多ECS實例并發(fā)讀寫訪問，具備高可靠、高并發(fā)、高性能等特點。為ECS實例提供了多實例掛載和IO攔截功能。共享盤是為了RAC的多實例并發(fā)讀寫共享存儲；
l云企業(yè)網(wǎng)CEN：云企業(yè)網(wǎng)（Cloud Enterprise Network，簡稱CEN）是阿里云提供的一款能夠快速構(gòu)建混合云和分布式業(yè)務系統(tǒng)的全球網(wǎng)絡服務，為用戶提供優(yōu)質(zhì)、高效、穩(wěn)定的網(wǎng)絡傳輸環(huán)境，幫助用戶打造一張具有企業(yè)級規(guī)模和通信能力的云上網(wǎng)絡。適用于集團企業(yè)、全球網(wǎng)絡等場景；
l轉(zhuǎn)發(fā)路由器TR（Transit Router）：提供連接網(wǎng)絡實例、自定義路由表、添加路由條目、添加路由策略等豐富的網(wǎng)絡互通和路由管理功能；該功能可以與CEN結(jié)合，實現(xiàn)Oracle RAC的INTERCONNECT多播網(wǎng)絡；
l云速搭CADT：通過模板實現(xiàn)Oracle rac自動編排。
在云平臺上以接近云原生的方式實現(xiàn)一個大型Oracle RAC的編排還是有點費勁的，哪怕是把Oracle RAC搭建好，并能夠承受高負載都不是一件很容易的事情。在云納管大型關(guān)鍵數(shù)據(jù)庫的時候，一般會采用裸金屬服務器或者虛擬化云主機兩種模式。如何對這兩種部署模式進行標準化設計并針對大型關(guān)系型數(shù)據(jù)庫進行優(yōu)化，其實是要事先考慮好的。阿里云的這個方案可以給我們一些啟示-網(wǎng)絡和存儲是其中最為關(guān)鍵的因素。
存儲方面，阿里可以提供高性能低延時的ESSD塊存儲。在我們自己的云環(huán)境里，也可以購買一些商用的高性能分布式存儲來構(gòu)建存儲資源池，專用于大型數(shù)據(jù)庫存放數(shù)據(jù)。這些存儲在優(yōu)化上必須滿足塊存儲的所有特征，能夠支持通用負載，這樣才能盡可能避免分布式存儲底層的不兼容而導致數(shù)據(jù)庫丟失IO，出現(xiàn)壞塊，引發(fā)數(shù)據(jù)安全的故障。在云主機的物理機上直接連接集中式存儲用于存儲數(shù)據(jù)庫的文件也是一種在云平臺技術(shù)無法滿足大型關(guān)系型數(shù)據(jù)庫需求時的一種常見做法，當年在數(shù)據(jù)庫遷移到VMWARE資源池的時候已經(jīng)有不少企業(yè)試用過這個方法，效果還不錯。無論使用哪種方法，確保IO的可靠性和穩(wěn)定性是關(guān)鍵。IO不能丟失，IO延時必須穩(wěn)定，并且最好不高于20毫秒，是云平臺必須為大型數(shù)據(jù)庫上云提供的保證。
另外一個方面是網(wǎng)絡，對于集中式數(shù)據(jù)庫還好，網(wǎng)絡問題不突出。對于Oracle RAC這樣對于集群網(wǎng)絡性能和可靠性要求十分高的場景，網(wǎng)絡要求就很高了。另外分布式數(shù)據(jù)庫對于集群網(wǎng)絡的性能與延時也是十分敏感的，必須為集群網(wǎng)絡提供高帶寬，低延時的虛擬網(wǎng)絡支持。實際上普通的大型數(shù)據(jù)庫對于網(wǎng)絡也有較高的要求，存儲網(wǎng)絡（使用IPSAN的場景）、備份網(wǎng)絡的帶寬和延時決定了數(shù)據(jù)庫是否有足夠的性能和易于運維管理。
除此之外，數(shù)據(jù)庫的前端連著應用，后端連著數(shù)據(jù)中臺，還和其他云上云下的業(yè)務系統(tǒng)保持著復雜的關(guān)系，因此對于云上的轉(zhuǎn)發(fā)路由器TR也有十分高的要求。而高可用切換、雙活等需求又要求VIP能夠很方便的漂移。虛擬大二層網(wǎng)絡的能力決定了雙活是否能跨機房甚至跨數(shù)據(jù)中心，這些都是要考慮的。阿里云的VPC、CEN-TR解決了這方面的后顧之憂。
對于分布式數(shù)據(jù)庫，還有一個麻煩的事情，那就是云存儲的多副本與分布式數(shù)據(jù)庫的多副本之間的多重副本機制帶來的問題。很多企業(yè)的分布式數(shù)據(jù)庫在云上是跑在云存儲上的，二者的副本機制會產(chǎn)生很高的疊加效應，既浪費了存儲資源，又影響了數(shù)據(jù)庫的性能。較為大型的高負載的分布式數(shù)據(jù)庫在云上部署最好采用裸金屬部署的模式，如果必須使用云主機，可以考慮使用集中式存儲或者使用單副本的云存儲。
