基於Oracle的私有云架構探析(連載一)

沃趣科技高級數據庫專家 魏興華

概述

雲是當今最爲熱門的一個話題或者說技術,在數據庫界也一樣,Oracle 12G這個名字不硬生生被掰彎成了Oracle 12C,數據庫雲在我看來能給企業帶來的第一價值是節省資源,提高服務器資源的利用率,隨着更快速CPU、更廉價大內存的出現,企業傳統孤島式的數據庫使用方式,一個主機一個實例,會導致大量的資源浪費,想當年在阿里B2B,有多少服務器的CPU利用率平均只有15%,現在都在倡導綠色數據中心,只有數據庫整合了,消耗的電少了,空調吹的少了,數據中心才能綠,地球才能綠(人可不能綠????)。在電剛出現的時候,每個富豪家裏都得買個發電機裝家裏,昂貴,噪聲大,擾民,還不環保,後來慢慢發展成電網,每一家只需要接入電網就可獲取電資源,不用去買發電機,現在的雲很大程度上跟這個很像,私有云平臺就像電網,用戶只需要接入雲平臺,就可以便捷的獲取資源。本篇文章主要講解如何構建一個Oracle的私有云平臺,主要從以下三個方面進行論述:


●數據庫整合技術的選擇

資源快速供應
服務質量管理


在開始闡述這三部分內容之前,有必要帶各位客官瞭解一些數據庫的部署現狀和相關的基本概念,例如DBaaS是什麼?爲什麼要用Oracle RAC來構建DBaaS。以及Oracle RAC的版本的一個發展歷史。【PS:本文都指的是私有云】


DBaaS

當今一些中大型企業有着成百上千的數據庫,這些數據庫可能有着不同的版本,不同的配置,甚至是在同樣的大版本下打着不同小版本補丁,這給企業帶來了非常大的成本和負擔:管理的成本、運維的成本、人員的成本、機房的成本、數據庫軟件licence的成本、存儲的成本等等,用一句話概括就是TCO的成本非常的大。此外,由於傳統的孤島式的數據庫使用方式,也導致了數據庫數量的激增和非常糟糕的敏捷性,每上一個業務,就要申請一批設備,一個機櫃,一個數據庫項目從立項到項目實施完成往往需要幾周甚至幾個月之久,如下圖:


由於非標準化的東西非常多:硬件環境多變、配置多變、架構多變,這給數據庫的可用性帶來了非常大的風險,由這些風險帶來的非計劃性的停機也給企業帶來了直接或間接的經濟損失、企業信譽的損失。由於近些年PC服務型的CPU性能越來越強勁,內存的價格越來越低,企業往往採購的服務器配置相對都較高,而很多企業還採用着一個主機只部署一個實例這種方式,導致了數據庫服務器的資源利用率非常的低下。根據GOOGLE的數字,28%的用戶平均每年的數據庫增長超過20%50%的用戶數據庫是沒有經過整合的。怎麼辦?


什麼是DBaaS?


以上面臨的場景和解決方案就是構建一個企業的DBaaS平臺對數據庫進行標準化整合,DBaaS 是一個標準化的、彈性可擴展的平臺,基於網絡訪問,通過一系列共享的數據庫服務,整合現有應用,以及快速部署新的應用。DBaaS私有云是部署於企業防火牆內的共享的數據庫服務。DBaaS一方面用來滿足開發、測試、QA的數據庫服務要求,通過簡單易用的自服務來滿足申請數據庫,schema等的需求。一方面幫助IT人員、DBA簡化了數據庫在標準平臺上的部署,減少維護工作,更好的支持客戶需求,更多的時間和預算用於創新。


RAC發展史概述

對於Oracle公司來說,構建數據庫雲的重擔會落在RAC上,RAC天然具有高可用、可擴展的特性,RAC版本變化與Oracle一樣,經歷了從I時代到G時代C時代,IInternetGGridCCloud,可以看出來Oracle的版本非常迎合時代標籤,這個G稍微有點悲劇,其實跟雲的概念非常像,但是最終Grid還是不敵Cloud包裝的好,最終還是得投入了雲的懷抱。Oracle 10G11GR1雖然都以G冠名,但是產品層面其實並沒有得力的配套技術,比如截止到11GR2之前,用戶使用RAC,客戶端還需要在連接描述符裏配置多個條目:




Grid的概念類似於電網的概念,作爲用戶只需要通過像插頭這樣的工具接入電網即可,不用去知道後面有多少發電站。對於11GR2之前的RAC來說,如果集羣的節點數發生了變化,還需要把客戶端裏配置都更新一遍,實在是很麻煩。所以Oracle到了11GR2版本發明了SCAN- Single Client Access Name,用戶只需要使用SCAN Name,在連接描述符裏配置一個條目就可以了

不管集羣有多大,都只需要配置這麼一行描述符就可以(ADDRESS所在行)。如同你使用Google,不管谷歌後臺有多少臺服務器,你都只需要輸入google.com,你不需要關心到底是後臺的哪個server爲你提供的服務。

以前客戶選擇使用RAC,大多數是由於單實例的性能不足,可用性不夠,現在雲的概念如日中天,使用RAC的理由可能已經演變爲建數據中心,做數據庫的整合。下圖爲Oracle各個版本的一些核心特性圖:


Oracle的核心功能在8I時就已經基本穩定下來了,但是這句話用在Oracle RAC產品上並不妥當,如上圖,在Oracle 8I時,Oracle RAC只能算是初具雛形,當時的名字還不叫Oracle RAC,而是叫OPS-Oracle parallel server,在這個版本里,Oracle推出了自己的動態鎖管理機制,Cache Fusion也已經出現,對於多個節點間的讀讀操作都已經能夠完全在內存中實現,但是多實例之間的寫操作仍然要通過磁盤作爲媒介。Oracle 9I版本,出現了GRD-Global Resource DirectoryCache Fusion算法變得成熟,充分利用了私有網絡的帶寬,通過集羣的私網來傳遞數據塊包括髒數據塊,真正的實現了內存融合。RAC區別於單機的最大一點是集羣間需要協商,通過協商來保證多個實例的行爲一致,而GRDDMLCache Fusion是實現協商的最重要技術,從Oracle RAC 8I9IRAC的這幾個核心功能變得成熟,但是不管是Oracle 8I還是9IOracle都沒有自己的集羣件產品、沒有自己的存儲解決方案,都要藉助於第三方廠商的集羣件產品和存儲解決方案,例如IBMveritas等。

但是到了Oracle 10G版本,霸氣顯露,Oracle已經不滿足於RAC數據庫本身了,一口氣推出了自己的集羣件Oracle ClusterWare 和存儲管理軟件ASM,並且Oracle ClusterWare在對外宣傳上不僅支持Oracle,還提供了API接口支持其他類型的APP。鑑於RACshared nothing的技術架構,共享存儲和集羣文件系統變得非常的迫切,在10G之前的版本,用戶必須藉助於第三方的存儲解決方案,例如veritas等第三方產品,無形中增加了產品的複雜度,因此在9I版本裸設備倒成了一個很大衆化的選擇。而10G出現的ASM解決了這一困境,ASM本身集卷管理和文件系統功能與一體,讓Oracle真正的具有了管理卷,管理文件的能力,不過這個版本下的ASM有點像是備胎的味道,畢竟是新技術,不成熟,很多DBA那時候還不敢用它。到了11GR1這個版本,單就Oracle RAC來說,非常讓人失望,幾乎沒有任何大的功能創新,似乎是爲了保證每五年左右推出一個大版本下的產物,集羣所有的核心功能都沒有任何改變,不過對於舊的功能像是ASM,在這個版本變得較爲穩定,而且也越來越多被DBA所接受。

到了11GR2發行後,一堆亮瞎眼的功能出現,似乎讓我們想明白了爲什麼11GR1會沒什麼新特性,因爲11GR2發佈的這些新特性是一攬子的雲化解決方案:RAC One Node ,ServerPool ,Scan,Instance CagingACFS等等這些新技術都是爲數據庫整合,爲雲而生的,之前的ClusterWare也在11GR2版本被重新包裝成爲了GridASM也被整合進Grid中作爲集羣的基礎組件。後續的章節,我們也會對其中一些關鍵的技術做詳細的講解。到了12C版本,Oracle推出了Flex Cluster ,Flex ASM,更大程度提高了RAC的可用性和可擴展性,IN-Memory的出現也更讓實時計算變得可能,CDB讓數據庫整合的方式更加多樣,密度也可以更大。從以上RAC的發展史可以看出來,從11GR2版本開始,Oracle開始真正的從產品層面配合雲的概念,我們本文講解的技術也都是在11GR2之後出現的技術。

數據庫整合技術

整合所需要的硬件平臺



雲的核心是整合,既然要做數據庫的整合,對於平臺的整體能力要求會比較高,這個能力不但包括性能,對於可用性、可擴展的要求都會比較高。筆者認爲做數據庫整合的理想平臺是一體機平臺,像ExadataQData,但是Exadata的價格實在是過於昂貴,性價比非常低,一般用戶難以負擔得起。筆者所在的沃趣科技是一家業界知名的做高性能解決方案的公司,我們是國內最早開始做一體機的廠商,QDATA一體機也是我們的明星產品,價格上相對於Exadata優勢很大。很多朋友會問到,Exadata最爲亮眼的地方是它的存儲卸載功能,你們QDATA一體機有嗎?對於這點我本人實在不敢苟同,試問有多少客戶真的從卸載功能裏受益非常大?就像Oracle 12C 推出了IN-Memory,理論上可以提升幾十上百倍的性能,但是我去的幾位客戶那裏做性能調優,發現客戶業務系統的SQL並沒有因爲使用了IN-Memory而變快,因爲使用IN-Memory有一些前提條件,而客戶系統並不滿足這樣的前提條件,其實不管是針對In-Memory還是存儲卸載功能,都需要DBA做一定的技術學習和精細化的調優工作,否則想發揮出它的能力是很難的,而且很多業務本身並不適合用這些特性,因此並不是上了這個IN-Memory或者卸載就能得到巨大的性能提升,例如使用上存儲卸載必須要全表掃描,而你的SQL可能使用到了索引,那麼你就要考慮是否需要把這個索引幹掉以用到卸載功能,而這個索引是不是能被幹掉,你又不確定,怕其他SQL引用這個索引,這種情況可能在客戶那是一種非常普遍的情況。

就我這些年的從業經歷來看,傳統的數據庫架構最大的問題是它的整體性能不匹配,例如傳統IOE架構最容易成爲瓶頸的地方,不是CPUMemory,而是IO,筆者在沃趣工作的不到兩年裏,接觸了N多客戶的性能瓶頸,很多都是IO問題(還有少數是索引沒優化好)。對於熱點數據較多較離散的OLTP系統來說,最爲關注的是IO的延遲和整體的IOPS,而傳統架構大多跑在機械盤上,因此IO的延遲非常大,並且機械盤能夠提供的IOPS也非常的低,因此傳統架構對於OLTP的支持就有明顯的瓶頸,我們的QDATA一體機是通過使用全SSD閃存或者FLASHCACHE方案來加速IO的讀寫時間,解決IO性能瓶頸。而對於OLAP系統來說,最爲關注的是數據庫系統能夠提供的IO吞吐量,傳統IOE架構,吞吐量往往在幾百M12GB的量級,因此吞吐量就成爲明顯的瓶頸,Exadata通過使用infiniband網絡來解決存儲到計算節點的IO帶寬的問題,同樣對於我們的QDATA也是通過使用infiniband來提供高帶寬。在傳統架構中,由於性能組件之間配置的失調,導致了很多資源雖然非常的充足但是根本利用不到,就如剛纔分析的,IO成爲瓶頸後,即使CPU資源再富足,也沒法利用到,因爲都在等IO

而新的高性能解決方案,如一體機產品,基本都是聚焦於解決傳統架構裏性能組件之間失調的問題,讓IO延時、IO吞吐、CPU、內存這些性能組件更加好的匹配在一起,不會在任何一點上成爲明顯瓶頸。而一體機作爲一款高性能解決方案,完全符合了這些要求。它能提供的IOPS動輒幾十萬,幾百萬,IO吞吐更是輕輕鬆鬆幾十GB,特別是隨着100Gbinfiniband的出現,一體機能夠提供的吞吐量會更加的大。我相信一體機的市場以後也會越來越大,不管是用它做私有云,還是爲核心業務保駕護航,都是一個非常值得考慮的選擇。同時一體機產品因爲都是預先集成與優化的,這裏麪包含了我們十幾年的運維經驗和性能優化經驗,例如我們對高TPS的系統預先做了REDO寫的優化,把REDO放在了具有RAID卡緩存的磁盤上,保證日誌的寫延遲足夠的穩定足夠的低。

作爲一名技術人員非常喜歡聊一些炫酷的技術,例如Exadata的卸載,我也是如此,如果你有興趣,我可以跟你滔滔不絕聊上一整天的Exadata,理論上講起來非常的浪漫和美好,但是現實情況比較殘酷,很多甲方DBA認爲上了Exadata後利用卸載功能就能讓查詢快的飛起來,結果大失所望。學習Exadata的成本非常高,並不是一種用了就能好的萬能藥。如果你有比較強的DBA團隊,還有大把的鈔票,還是可以考慮使用下Exadata的,如果你的DBA團隊暫時還達不到這個要求,那麼建議還是不要花這冤枉錢。

Exadata的卸載看似一項跨時代的創新,其實不然,它其實是向MPP架構致敬的一項功能,Oracle的Share Everything 的架構導致了存儲一定需要是共享的,進而導致計算與存儲必須分離,這種架構裏存儲不具備MPP架構中,每個節點都能處理數據的能力,因此Oracle的Exadata的出現一定程度上解決了這個問題,讓存儲節點在某些條件下具備了處理數據的能力。

數據庫整合方案比對

虛擬化一度成爲一種流行的數據庫整合的方案(特別是MYSQLPG),但是它的弊端非常的明顯,虛擬化整合方案需要額外管理更多的OS,而且虛擬化本身會帶來IO性能的大幅度衰減,因此性能上比較差,能夠整合的數據庫的密度也就比較小,不過就隔離性來說,由於每個虛擬機都有獨立的OS,因此除了共享宿主機以外,OS,實例等等都是隔離的,很多用戶選擇這種整合方案很大程度上也是被它的強隔離性所吸引。

單機多實例也是很多客戶在使用的整合方案,在一個主機上部署多個實例,由於共享了主機和OS,性能損耗小,因此整合的密度可以比較大(相對於虛擬化整合),而且通過11GR2Instance Caging技術可以做實例間CPU資源的隔離,由於單機多實例方案比虛擬化整合方案多共享了OS這一層,因此隔離線上相對於虛擬化方案來說,降低了一些,不過上面已經提到通過Instance Caging技術可以做到CPU的隔離。多schema方式的整合,就我們接觸到的客戶來說,也有客戶在用,它的缺陷非常的明顯,資源隔離不好做,業務上限制也比較大,同名的schema怎麼做整合?幾個schema間創建的一些公共權限有衝突怎麼辦?而且本身由於在一個數據庫內,數據庫的權限隔離也比較難做,就隔離性來看,因爲共享了主機、操作系統、實例,它的隔離級別非常低,從長遠來看,後期如果要做拆分,只能使用邏輯遷移,而邏輯遷移往往是非常複雜的。Oracle12C版本發佈了可插拔數據庫,它是一個優缺點都比較中和的解決方案,相對於單機多實例來說,它的隔離性沒那麼強,但它整合的密度可以做到非常的大,因爲它像schema整合方案一樣,共享了主機、OS、實例(下圖),因此性能損失非常的少,總體上,它的隔離性和安全性又比schema方案要強很多,因爲本質上每一個PDB都是一個完整獨立的DBDB之間沒辦法互相訪問,除非通過DBLINK這樣的工具。

以上種種,筆者推薦的整合方案是基於單機多實例或基於12C的可插拔的方案,但是12C畢竟目前使用的人還不多,因此需要仔細考慮BUG帶來的一些風險。



發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章