?前陣子參與一個(gè)客戶的XC方案編制，領(lǐng)導(dǎo)要求XC工作必須和上云作為一件事來做，通過XC加速上云的進(jìn)展。這就讓數(shù)據(jù)庫XC工作變得更為復(fù)雜起來了。云廠商提供的RDS大家確實(shí)喜歡用，不過XC數(shù)據(jù)庫都無法作為RDS提供出來，云廠商為開發(fā)這些數(shù)據(jù)庫的RDS支持開出了一個(gè)不低的價(jià)格。而將XC數(shù)據(jù)庫部署于裸金屬環(huán)境后進(jìn)行云納管，又不符合這個(gè)企業(yè)上云的基本IT政策，不被領(lǐng)導(dǎo)認(rèn)可。這讓云管部門大傷腦筋。如果僅僅把XC數(shù)據(jù)庫部署到ECS云主機(jī)中，雖然能用，但是能不能用好，大家心里也都沒有底。XC數(shù)據(jù)庫廠商信誓旦旦沒問題，不過談到關(guān)鍵大型應(yīng)用系統(tǒng)的時(shí)候，大家又不敢打包票了。

向云遷移是近年來IT發(fā)展的趨勢(shì)，這個(gè)大方向總是沒錯(cuò)的。不過再好的事情也是有局限性和缺點(diǎn)的，所以大部分企業(yè)都不會(huì)采取一刀切的做法，而是會(huì)留下一些余地，因?yàn)樯显撇皇亲罱K目的，確保更好的支撐業(yè)務(wù)才是IT部門上云的目的。如果強(qiáng)行上云并不能很好地支撐業(yè)務(wù)系統(tǒng)，采用這種比較僵化的一刀切的做法，也不是很妥當(dāng)?shù)摹?/p>

數(shù)據(jù)庫上云一直是被吐槽的比較多的，雖然目前各大云廠商都有RDS產(chǎn)品，不過國(guó)內(nèi)的RDS產(chǎn)品主要集中在一些開源數(shù)據(jù)庫上，比如MySQL、PG、MongoDB、Redis等。而企業(yè)使用的數(shù)據(jù)庫不一定能在這個(gè)清單里找到。因此就不可避免地需要把數(shù)據(jù)庫放到ECS云主機(jī)里去跑。

RDS和跑在ECS里的數(shù)據(jù)庫性能上還是有不少差異的，因?yàn)镽DS里的數(shù)據(jù)庫是跑在裸金屬服務(wù)器中的，云平臺(tái)的云底座對(duì)這些裸金屬服務(wù)器做了納管支持，這些數(shù)據(jù)庫使用的是本地磁盤，因此在性能上還是有保障的。如果選擇高性能SSD盤的RDS，那么IO延時(shí)，IO吞吐能力都可以和傳統(tǒng)架構(gòu)的數(shù)據(jù)庫系統(tǒng)相媲美。唯一受限的就是單機(jī)的容量。目前在云平臺(tái)中的RDS都是有規(guī)格的，每個(gè)規(guī)格的RDS不僅僅限制了CPU、內(nèi)存、IOPS等，也限制了單個(gè)數(shù)據(jù)庫的大小。

和RDS不同，ECS具有更好的彈性，CPU、內(nèi)存、存儲(chǔ)容量都可以彈性擴(kuò)充，只不過ECS是完全跑在云底座上的，其存儲(chǔ)介質(zhì)往往使用云底座中的分布式存儲(chǔ)，在IO吞吐能力、IO延時(shí)方面存在一定的不足。有些云廠商支持ECS集中式存儲(chǔ)的LUN，從而獲得高性能存儲(chǔ)的支持。不巧的事，SAN SWITCH目前找不到國(guó)產(chǎn)替代方案，在一些較為嚴(yán)格的XC項(xiàng)目中無法使用這個(gè)方案，只能通過分布式存儲(chǔ)或者IPSAN來提供存儲(chǔ)。當(dāng)然這也是一個(gè)值得吐槽的槽點(diǎn)，SAN SWITCH的使用量是有限的，而且使用年限也很長(zhǎng)。如果怕被卡脖子，現(xiàn)在抓緊多買一批也沒多少錢，等這批用壞了，國(guó)產(chǎn)產(chǎn)品估計(jì)也跟上來了。這種片面追求完全自主可控的玩法，也是給XC工作帶來了更大的難度。

實(shí)際上對(duì)于數(shù)據(jù)庫上云的吐槽，還是很多的。前陣子在flashdba網(wǎng)站上看到一個(gè)Oracle OCM收集的對(duì)于數(shù)據(jù)庫上云的吐槽，十分有同感。今天在這里和大家分享一下。其實(shí)老外吐槽的內(nèi)容和我們差不多，對(duì)于業(yè)務(wù)關(guān)鍵型應(yīng)用程序工作負(fù)載，其特點(diǎn)包括大型、復(fù)雜、可靠性要求高、任務(wù)關(guān)鍵、敏感、性能要求高……，在本地部署時(shí)，它們肯定在專用的高端基礎(chǔ)架構(gòu)上運(yùn)行。當(dāng)你要把它們遷移到云上時(shí)，肯定會(huì)遇到問題的。

因?yàn)樵票举|(zhì)上是一個(gè)巨大的離散資源和服務(wù)池，可以按需滿足你的資源與服務(wù)請(qǐng)求。你可以方便的在云上托管一個(gè)MySQL實(shí)例，也可以快速獲得幾百臺(tái)ECS云主機(jī)。如果您有預(yù)算，云就有辦法讓您花錢。不過無論您是使用云提供商提供的RDS數(shù)據(jù)庫，還是在ECS上安裝數(shù)據(jù)庫軟件，您都在與數(shù)百個(gè)甚至數(shù)千個(gè)其他系統(tǒng)共享該基礎(chǔ)架構(gòu)、共享可用性能力、共享性能。一旦云出現(xiàn)任何問題，那么這一籃子雞蛋也都會(huì)受到影響，雖然云廠商說云是高可靠的，安全的，這些年公有云的故障也不是個(gè)例了。我遇到一個(gè)用戶，在面對(duì)這個(gè)難題的時(shí)候，選擇了一種十分無奈的做法，他們把應(yīng)用服務(wù)器的一半部署在云上，一半部署在云下，數(shù)據(jù)庫的主/備環(huán)境分別位于云上和云下。這種做法實(shí)際上系統(tǒng)的復(fù)雜度和運(yùn)維的難度都大大增加了。實(shí)際上系統(tǒng)上線后，大問題沒有，小問題還是頻發(fā)的。

對(duì)于能夠IOE環(huán)境中通過徹底改造遷移的系統(tǒng)，上云還是比較容易的。而對(duì)于一些暫時(shí)無法進(jìn)行全面改造的系統(tǒng)，那么就只有基礎(chǔ)設(shè)施遷移這一條路可走了。而這種遷移往往也面臨一些大坑。

首先我們會(huì)遇到IO的巨大挑戰(zhàn)。以往Oracle等大型數(shù)據(jù)庫系統(tǒng)依靠集中式存儲(chǔ)或者本地高性能硬盤的IO低延時(shí)來確保其穩(wěn)定與高性能的提供服務(wù)。而這一切在云上似乎很難得到保證。在云中獲得大量計(jì)算能力相對(duì)容易。但是如果你要求讀取和寫入非常快、并且在可預(yù)測(cè)的響應(yīng)時(shí)間完成，云平臺(tái)就不一定能夠很好的給予支撐了。如果IO延遲、IOPS 或吞吐量是十分關(guān)鍵的，那么你可能就會(huì)遇到比較難以解決的問題。

一些公有云的用戶都會(huì)有這種感受，并不是云廠商不能提供這些能力，而是你的錢袋子不足以購買到這些能力。很多公有云用戶都有這種感受，那就是性能和成本是一枚硬幣的兩個(gè)面，你很難一眼看到所有的東西。我們可以在公有云上去選你所有需要的菜，不過大多數(shù)用戶在點(diǎn)菜時(shí)都遇到過類似身材不是很標(biāo)準(zhǔn)的人買襯衫時(shí)的尷尬。就像我這種偏胖的人，是很難買到合適的襯衫的，領(lǐng)子和胸圍合適的襯衫往往袖子就長(zhǎng)了點(diǎn)，而袖子合適的襯衫往往就太貼身了。

在云平臺(tái)上點(diǎn)菜也是如此，S號(hào)的云主機(jī)可能是40美金，M號(hào)的要120，而L號(hào)的最劃算，只要160，不過這不是我需要的，我需要穿XXL，什么？你必須為XXL支付400美金。

實(shí)際上這還是好的，只要你付得起錢，你就可以很快獲得你所需要的襯衫。過度的配置會(huì)讓你有限的預(yù)算更加雪上加霜。云廠商的RDS或者ECS就像是餐廳里配好的菜肴，你想要辣子雞丁里多點(diǎn)雞丁，少點(diǎn)辣椒是沒辦法的，CPU，內(nèi)存，IO能力往往都是配套提供的，你無法按需選取。如果你想要一個(gè)3萬IOPS的存儲(chǔ)系統(tǒng)，不好意思，云廠商的存儲(chǔ)系統(tǒng)是按照每個(gè)GB來配置的，你要買這么多的IOPS，必須購買5TB的云存儲(chǔ)才能獲得。而有可能你只需要在上面部署一個(gè)500GB的數(shù)據(jù)庫。

目前谷歌和亞馬遜已經(jīng)開始提供更為精細(xì)的價(jià)格體系，可以通過為IOPS額外付費(fèi)來避免此類問題出現(xiàn)，這是一個(gè)很好的現(xiàn)象。

如果說這一切發(fā)生在公有云上，那對(duì)于用戶來說，只能默默地接受。而事實(shí)上我在很多私有云環(huán)境中也看到了類似的情況。云管部門為了便于管理，也像公有云一樣，推出了一系列的標(biāo)準(zhǔn)化的產(chǎn)品，你只能從菜單中點(diǎn)選有限的選項(xiàng)，和公有云用戶沒有太大的區(qū)別。云運(yùn)營(yíng)部門并不了解數(shù)據(jù)庫應(yīng)用的需求和特點(diǎn)，他們只是一廂情愿地進(jìn)行管理。于是在公有云上發(fā)生的一切，在自建的私有云上并沒有得到解決。