本文來自微信公眾號“白鱔的洞穴”,作者/白鱔。
經(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ù)庫在云上部署最好采用裸金屬部署的模式,如果必須使用云主機,可以考慮使用集中式存儲或者使用單副本的云存儲。