爲何要"去IOE"

2013年5月17日,阿里集團最後一臺IBM小機在支付寶下線。這是自2009年「去IOE」戰略透露以來,「去IOE」很是重要的一個節點。「去 IOE」指的是擺脫掉IT部署中原有的IBM小型機、Oracle數據庫以及EMC存儲的過分依賴。告別最後一臺小機,意味着整個阿里集團儘管還有一些Oracle數據庫和EMC存儲,可是IBM小型機已所有被替換。2013年7月10日,淘寶重中之重的廣告系統使用的Oracle數據庫下線,也是整個淘寶最後一個 Oracle數據庫。這兩件事合在一塊兒是阿里巴巴技術發展過程當中的一個重要里程碑。html


何謂IOE?數據庫

IOE 這個說法來自阿里技術團隊內部的稱謂,而後纔在整個業界流傳開來。IOE是傳統IT三大件,指以 IBM 、Oracle、EMC 爲表明的小型機、集中式數據庫和高端存儲的技術架構。服務器

I 指 IBM p 系列小型機,操做系統是 AIX(IBM 專有的 Unix 系統);網絡

O 指 Oracle 數據庫(RDBMS);架構

E 指 EMC 中高端 SAN 存儲。併發


爲何要去IOE?負載均衡

阿里巴巴過去一直採用的是Oracle數據庫,並利用小型機和高端存儲設備提供高性能的數據處理和存儲服務。隨着業務的不斷髮展,數據量和業務量呈爆發性增加,傳統的集中式Oracle數據庫架構在擴展性方面遭遇瓶頸。分佈式

傳統的商業數據庫軟件(Oracle,DB2),多以集中式架構爲主,這些傳統數據庫軟件的最大特色就是將全部的數據都集中在一個數據庫中,依靠大型高端設備來提供高處理能力和擴展性。集中式數據庫的擴展性主要採用向上擴展(Scale up)的方式,經過增長CPU,內存,磁盤等方式提升處理能力。這種集中式數據庫的架構,使得數據庫成爲了整個系統的瓶頸,已經愈來愈不適應海量數據對計算能力的巨大需求。高併發

傳統架構在主機端大多經過兩臺主機共享存儲設備,平時其中一臺主機使用存儲經過數據庫軟件來管理。這樣的架構只能有一臺主機(RAC除外)上的數據庫可以提供服務,另外一臺主機只能是做爲熱備冗餘,不能啓動數據庫實例提供服務。因此,其處理能力就徹底取決於這臺主機的最大擴展能力,很難經過增長主機數量來增長處理能力。而單臺主機的擴展能力畢竟是有限的,即便是某些廠商的大型機,一樣也有其擴展限制。此外,傳統架構對高端設備的依賴,無疑將直接致使系統成本的大幅度增長,甚至可能會致使系統被主機和硬件廠商所「綁架」,不得不持續增長投入成本。性能

在阿里看來,「IOE」實際上表明瞭一種高成本、高維護費、很不互聯網(不擅長處理大規模高併發的互聯網行爲)的商用數據庫系統,特別是阿里盤子愈來愈大,所須要付出的升級硬件和維護的代價也會愈來愈驚人,阿里巴巴採用數據切分(sharding)的策略,將部分海量數據應用從集中式Oracle切換到分佈式MySQL集羣,從縱向擴展到水平擴展,解決了數據庫擴展性的問題,並用PC服務器替換了小型機。事實上,這裏能夠作一個不那麼技術但比較簡單的理解:傳統的IOE表明的是集中式架構,而去IOE化其實就是推進分佈式架構代替集中式架構,也就是更好的擁抱雲計算—固然對阿里自己來講,用通俗的語言解讀出阿里雲甚至阿里的IT計算(甚至商業模式)發展路徑:

一、鑑於相似雙11這種超大規模併發行爲的產生,背後須要的計算資源很是龐大,因此整個阿里對IT資源的投入都是很是大的。
二、當投入大量的資源應對高峯期高併發時,低峯低併發時就形成了計算資源的冗餘,這個時候就能夠以雲計算的方式出租給中小企業。而固然企業就可能有更高的野心,好比把雲計算做爲主要的商業模式。可是對於那些對計算要求很高的公司,還不夠。

軟件決定總體架構,若是要動O,那麼I和E就必需要動 – 相信不會有人在小型機上跑 MySQL 的。




Oracle RAC不能知足擴展要求麼?
轉自:可擴展的分佈式數據庫架構

幾乎每一個數據庫產品都有集羣解決方案,Oracle RAC是業界最流行的產品。其架構的最大特色是共享存儲架構(Shared-disk),整個RAC集羣是創建在一個共享的存儲設備之上的,節點之間採用高速網絡互連。Oracle RAC提供了很是好的高可用特性,好比負載均衡和應用透明切換(TAF),其最大優點在於對應用徹底透明,應用無需修改即可以切換到RAC集羣。可是,RAC的擴展能力有限,首先由於整個集羣都依賴於底層的共享存儲,因此共享存儲的IO能力和可用性決定了整個集羣的能夠提供的能力,其依然沒法擺脫對 大型存儲設備的依賴。Oracle顯然也意識到了這個問題,在Oracle的MAA(Maximum Availability Architecture)架構中,採用ASM來整合多個存儲設備的能力,使得RAC底層的共享存儲也具有線性擴展的能力,整個集羣再也不依賴於大型存儲的處理能力和可用性。

RAC的另一個問題是,隨着節點數的不斷增長,節點間通訊的成本也會隨之增長,當到達某個限度時,增長節點可能不會 再帶來性能上的提升,甚至可能形成性能降低。這個問題的主要緣由是Oracle RAC對應用透明,應用能夠鏈接集羣中的任意節點進行處理,當不一樣節點上的應用爭用資源時,RAC節點間的通訊開銷會嚴重影響集羣的處理能力。因此使用 Oracle RAC有兩個建議:1.節點間通訊使用高速互聯網絡;2.儘量將不一樣的應用分佈在不一樣的節點上。基於這個緣由,Oracle RAC一般在DSS環境中能夠作到很好的擴展性,由於DSS環境很容易將不一樣的任務分佈在不一樣的計算節點上,而對於OLTP應用,Oracle RAC更多狀況下是用來提升可用性,而不是爲了提升擴展性。

相關文章
相關標籤/搜索