基於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時代，I是Internet，G是Grid，C是Cloud，可以看出來Oracle的版本非常迎合時代標籤，這個G稍微有點悲劇，其實跟雲的概念非常像，但是最終Grid還是不敵Cloud包裝的好，最終還是得投入了雲的懷抱。Oracle 10G，11GR1雖然都以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 Directory，Cache Fusion演算法變得成熟，充分利用了私有網路的頻寬，透過叢集的私網來傳遞資料塊包括髒資料塊，真正的實現了記憶體融合。RAC區別於單機的最大一點是叢集間需要協商，透過協商來保證多個例項的行為一致，而GRD、DML、Cache Fusion是實現協商的最重要技術，從Oracle RAC 8I到9I，RAC的這幾個核心功能變得成熟，但是不管是Oracle 8I還是9I，Oracle都沒有自己的叢集件產品、沒有自己的儲存解決方案，都要藉助於第三方廠商的叢集件產品和儲存解決方案，例如IBM，veritas等。

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

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

資料庫整合技術

整合所需要的硬體平臺

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

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

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

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

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

資料庫整合方案比對

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

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

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