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

向云遷移是近年來IT發展的趨勢，這個大方向總是沒錯的。不過再好的事情也是有局限性和缺點的，所以大部分企業都不會采取一刀切的做法，而是會留下一些余地，因為上云不是最終目的，確保更好的支撐業務才是IT部門上云的目的。如果強行上云并不能很好地支撐業務系統，采用這種比較僵化的一刀切的做法，也不是很妥當的。

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

RDS和跑在ECS里的數據庫性能上還是有不少差異的，因為RDS里的數據庫是跑在裸金屬服務器中的，云平臺的云底座對這些裸金屬服務器做了納管支持，這些數據庫使用的是本地磁盤，因此在性能上還是有保障的。如果選擇高性能SSD盤的RDS，那么IO延時，IO吞吐能力都可以和傳統架構的數據庫系統相媲美。唯一受限的就是單機的容量。目前在云平臺中的RDS都是有規格的，每個規格的RDS不僅僅限制了CPU、內存、IOPS等，也限制了單個數據庫的大小。

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

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

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

對于能夠IOE環境中通過徹底改造遷移的系統，上云還是比較容易的。而對于一些暫時無法進行全面改造的系統，那么就只有基礎設施遷移這一條路可走了。而這種遷移往往也面臨一些大坑。

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

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

在云平臺上點菜也是如此，S號的云主機可能是40美金，M號的要120，而L號的最劃算，只要160，不過這不是我需要的，我需要穿XXL，什么？你必須為XXL支付400美金。

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

目前谷歌和亞馬遜已經開始提供更為精細的價格體系，可以通過為IOPS額外付費來避免此類問題出現，這是一個很好的現象。

如果說這一切發生在公有云上，那對于用戶來說，只能默默地接受。而事實上我在很多私有云環境中也看到了類似的情況。云管部門為了便于管理，也像公有云一樣，推出了一系列的標準化的產品，你只能從菜單中點選有限的選項，和公有云用戶沒有太大的區別。云運營部門并不了解數據庫應用的需求和特點，他們只是一廂情愿地進行管理。于是在公有云上發生的一切，在自建的私有云上并沒有得到解決。