企業級數據庫云平臺的建設與運維方案

梁 勇，張攀翔，陳秋華

（中國移動通信集團公司廣東分公司 廣州510623）

1 引言

傳統電信企業的系統建設過程中，由于需求變化快速、系統數量巨大，系統建設往往按照各自應用需求來評估、采購、建設、維護各個應用獨立的主機、存儲、網絡、數據庫、應用服務器等資源，從而導致了豎井式或煙囪式的多套獨立的系統，這種建設方式帶來了大量的問題。

·項目建設周期漫長，難以快速滿足市場需求。

·購買了大量不需要的處理能力。系統前期很難準確估算業務量和需要采用怎樣的數據庫資源支撐，導致某些系統的數據庫長期處于非常空閑的狀態，浪費了投資。

·缺乏集中管理和安全性保護。由于每個系統獨立建設，每個系統的可用性、安全性都依賴于SI單獨實現，規劃復雜，實施難度大，導致較大的系統管理和安全性漏洞。

·難以隨著業務需求的變化調整數據庫資源，存在平時大量資源利用率普遍偏低和業務高峰值時資源不足的矛盾。例如，在中國移動通信集團公司某分公司負責建設和運維的增值業務中，有數十個獨立的數據庫平臺，“139說客”的核心數據庫服務器的平均CPU負荷長期在60%以上，而峰值可以長達24 h超過90%，帶來了很大的系統運行質量的隱患，也可能由于負荷高影響了業務響應時間，導致客戶感受的受損。反之，也有不少數據庫主機長期平均負荷在5%以下，甚至持續看不到任何負載，造成了投資上的浪費。

因此，亟需打破原來這種煙囪式的建設方式，隨著云計算技術的逐漸成熟和完善，通過云計算技術實現系統資源的共享、動態調整和按需分配，成為電信企業未來主要的探索方向。計算基礎設施的發展如圖1所示。

從電信企業系統運行情況來看，其核心的服務器和存儲資源的50%以上是作為數據庫平臺部署的，所以如何實現電信級對數據庫云平臺的靈活部署，既可以實現“大分小”式，又可以實現“小合大”式的應用部署，對電信企業運營商而言極為重要。

圖1 計算基礎設施的發展

2 云計算背景知識

2.1云計算概念

NIST對云計算的定義：云計算模型能以按需方式，通過網絡方便地訪問云系統的可配置計算資源共享池(如網絡、服務器、存儲、應用程序和服務)，同時以最少的管理開銷及與供應商的交互，迅速配置提供或釋放資源。

云計算是網格計算 （grid computing）、分布式計算（distributed computing）、并行計算（parallel computing）、效用計算（utility computing）、網絡存儲技術（network storage technology）、虛擬化（virtualization）、負載均衡（load balance）等傳統計算機和網絡技術發展融合的產物。

2.2 云計算的服務模式

云計算是以服務的形式提供IT化能力。云計算所提供的服務形式可以分為IaaS（infrastructure as a service）、PaaS（platform as a service）、SaaS（software as a service），如圖2所示。

圖2 云計算的3種服務模式

IaaS主要關注基礎設施（即硬件）虛擬化、資源共享、資源調配等硬件服務能力的提供，如果面向系統建設考慮，仍然需要進一步部署相應的平臺軟件（數據庫、中間件等）和應用軟件，所以IaaS層提供的云服務管理粒度只在硬件層面，對平臺軟件和應用軟件的部署和管理幾乎沒有涉及。

在提供云服務的過程中，硬件作為基礎設施層，仍然需要承載平臺和應用軟件能力，所以大部分企業更多地關注業務層面的平臺軟件方面的服務化，即PaaS層服務能力。IOUG對企業客戶云計算服務的關注調查如圖3所示。

PaaS層主要關注提供平臺軟件的服務能力 （如數據庫、中間件等），所以實現PaaS層服務模式，可以有兩種技術選擇：一種是基于IaaS層提供的硬件基礎設施，再通過PaaS管理平臺來部署和管理平臺軟件服務；另一種是直接通過一體化的解決方案來實現軟、硬件的統一管理、部署、資源分配和回收。前一種方式存在管理的復雜性、兼容性問題，甚至還可能存在嚴重的性能瓶頸和整體運行風險的問題。如中國移動通信集團公司廣東分公司（以下簡稱廣東移動）在基于x86服務器上通過虛擬化技術來實現IaaS層資源池，再部署Oracle數據庫和業務應用，通過實際測試發現，性能損耗超過40%，而且還存在Oracle RAC數據庫沒有在VMWare平臺得到廠商官方支持的問題，一旦遇到系統問題，診斷、解決時都存在很大的潛在運行風險。

圖3 IOUG對企業客戶云計算服務的關注調查

通過軟硬件一體化PaaS層云服務，形成共享資源池，同時提供平臺級軟件能力，然后按照各個應用需求在PaaS資源池中申請硬件資源、獲得軟件服務的方式，不斷部署不同的業務應用，實現系統的集中化整合。這樣可以有效節省計算和存儲資源、機房空間、耗電和配套設施、人力維護成本，提高系統的可靠性、擴展能力、計算能力，避免出現業務要求和系統支撐能力不匹配的問題。

3 電信級數據庫云平臺理想架構和最佳實踐

3.1 電信級PaaS數據庫云平臺的理想架構

根據以上分析，從效率、管理、集成、兼容性角度來看，實現數據庫云平臺的最佳方式是軟、硬件一體化PaaS平臺解決方案，而PaaS云一體化解決方案需要從4個主要方面考慮。

·構建可不斷堆疊、可線性擴展、分布式的服務器資源池；

·構建可不斷堆疊、可線性擴展、分布式的存儲資源池；

·構建服務器與服務器之間、服務器與存儲之間的高速互聯網絡；

·構建軟硬一體化、統一的云管理和云治理平臺。

由于在電信系統中，數據庫呈現多元化和混合型特點。既有大量的小規模數據庫，如增值業務系統、政企客戶系統等，也有很多超大規模數據庫，如計費、CRM、話務網管等；既有OLTP為主的系統，如CRM、呼叫中心等，也有很多以OLAP型為主的系統，如數據倉庫、數據集市等，還有很多OLTP和OLAP混合型系統，如結算、賬務、網管等，既有以本地區為主導的系統，又有全國型集中化的系統。所以對數據庫云平臺的要求也呈現出一定的電信級要求。

·靈活的資源分配和管理能力，可以同時支持“大分小”和“小合大”兩類要求。

·混合型數據庫架構，既可以支持“數據庫集群”型的OLTP交易，又可以支持 “數據庫集群”型的OLAP處理。

·極高的處理性能，保證數據庫云平臺可以支撐大量數據庫應用。

·極高的擴展能力，保證數據庫云平臺可以不斷地線性擴展。

·極高的可靠性，保證業務的連續性。

·高性價比、低能耗。

·完善、統一、可視化的管理能力。

滿足電信級數據庫PaaS云平臺要求的理想架構，需要軟件和硬件的有機結合來構成，每個組成部分既需要硬件能力，也需要軟件特性配合來實現整體目標。

3.1.1 計算資源池

從硬件來看，這一部分是運行數據庫的主要部分，需要實現低成本化堆疊、分布式網格計算能力，所以需要多服務器、多CPU協同、網格集群化的運行環境。為了實現這個目標，利用低成本的x86架構的多服務器堆疊，配合共享磁盤架構數據庫集群是最理想的架構，因為多臺x86架構可以提供低成本、快速的擴展能力，但與小型機相比，x86架構的可靠性不夠，可以通過共享磁盤架構的數據庫集群來提高整體運行的可靠性，同時能夠發揮多服務器的分布式并行處理能力。

從軟件來看，計算資源池要求能夠對資源進行靈活的分配和管理，既可以將一個服務器的部分資源分配給一個特定應用，即“大分小”，也可以將多個服務器資源整合成為一個應用，即“小合大”。同時還能夠在資源池內部和外部按照需要動態調整原有分配的資源關系，比如隨需增加或減少一個應用服務所占的CPU、內存等。

3.1.2 存儲資源池

從硬件來看，作為數據庫的存儲部分，具備低成本、分布式并行特點，可以通過多個小的存儲單元堆疊方式不斷地進行線性擴展，構成大規模存儲資源池；同時作為數據庫存儲，需要具備大容量的多級緩存機制，使得數據庫中的熱點數據可以通過緩存來提高處理性能；另外隨著數據量的不斷增加，存儲單元需要具備足夠的CPU和計算能力，參與到數據的預處理過程中來，以減輕數據庫服務器所需處理的數據量。

從軟件來看，由于電信企業數據規模的不斷增加，特別是網絡運維應用包含大量的網元數據，需要存儲具備較高的數據壓縮比，以節省存儲空間，另外存儲側可以通過并行化的方式對數據進行預分揀和預過濾，提高數據的處理效率。

3.1.3 網絡互聯

圖4 網絡互聯技術

在數據庫云平臺方面，需要采用大量的主機集群及存儲集群，為了讓這些集群能夠發揮最佳的效果，必須使用效率最高的內部網絡把它們連接起來，目前比較成熟的網絡技術主要有萬兆以太網以及Infiniteband，如圖4所示。這兩種技術都可以提供高速的內部連接，用來實現主機之間的集群連接、存儲單元之間的互聯以及主機到存儲單元之間的數據連接。

3.2 符合電信級PaaS數據庫云平臺要求的最佳實踐

從目前實踐來看，要符合電信級數據庫PaaS云平臺的要求，Oracle的Exadata數據庫云服務器是一個理想選擇。

3.2.1 分布式服務器資源池

Exadata數據庫云服務器可以通過整合多服務器的計算資源，形成一個巨大的資源池，許多不同的數據庫可運行于同一Exadata數據庫機器上。

DB服務器通過共享配置方式使不同數據庫應用運行在指定的資源范圍內，可以通過Service的方式實現數據庫服務的虛擬化，應用以Service的方式連接并運行于一個或多個動態的數據庫節點上，可以動態地增長、回收和移動。通過Service虛擬化可以實現“大分小”和“小合大”的虛擬化應用。

·大型數據庫可通過RAC技術跨越多個物理節點；

·多個小型數據庫可以通過共享運行于同一個物理節點。

對于多個數據庫運行于同一節點的情況，實例綁定（instance caging）技術提供可預知的CPU核心資源，可限制數據庫運行于特定的處理器的子集上，如圖5所示。

通過數據庫虛擬化和整合多應用數據庫于Exadata數據庫云平臺，可以使得各個應用數據庫的資源利用率得到有效的整合和提升，以節省更多的主機、存儲、機房、軟件License等資源。

如企業有3個主要應用在數據庫云平臺運行，3類應用分別以Sales App、ERP App和HR App表示，如圖6所示。數據庫云平臺可以分別給3類應用構建服務器資源池（server pool）和空閑資源池（free pool），3 類應用分別通過相應的數據庫服務接口連接Exadata數據庫云平臺。根據實際業務需求，銷售部門應用需要持續地使用較多的數據庫云資源，數據請求需要優先得到滿足。ERP類應用對數據庫云資源的需求彈性較大，隨商務周期可能會有所變動，同時數據請求的優先級較銷售部門低。HR類應用對數據庫云資源需求相對固定，且所需的資源最少，數據請求的優先級最低。Exadata數據庫云平臺可以按照每類應用對資源的需求進行管理和動態供應。

在Exadata數據庫云服務器中，不同應用數據庫部署在多個數據庫服務器集群中，當應用負載和請求增長時，原有計算資源不足以滿足要求，服務質量會下降(預定義策略)，數據庫服務可以在數據庫云平臺中動態擴展到資源空閑的服務器中運行，提高該服務的服務質量。

3.2.2 分布式存儲資源池

Exadata數據庫云服務器本身就集成了ASM （自動存儲管理）的存儲管理功能，用來實現存儲的虛擬化、高擴展、高可靠的特點。

通過Oracle ASM進行存儲虛擬化后，不但可以實現存儲的性能水平擴展，而且可以實現存儲的高可用、自管理能力。加入ASM管理的存儲可以劃分為不同的磁盤組，當數據存儲在磁盤組中時，數據會均勻分布到磁盤組的各個存儲單元，實現數據均勻分布，當磁盤組中增加或減少存儲單元數量時，數據會被動態地重新分布，避免出現任何的熱點磁盤。

圖5 實例綁定技術

圖6 數據庫云平臺的3類應用

圖7 智能存儲技術的處理

Exadata將數據庫計算分成計算密集型處理和存儲密集型處理，分別在DB服務器和存儲服務器完成。采用智能存儲技術（Smart Scan），實現了存儲層完全并發式、智能化的預處理，提高了數據的處理效率，并降低了DB服務器的處理負擔，如圖7所示。

3.2.3 高性能互聯網絡

Oracle Exadata Storage在服務器和存儲之間使用了Infiniband互連。Exadata單元具有高可用性的雙端口4倍數據速率(QDR)Infiniband連接。每個Infiniband連接提供了40 GB的帶寬，高于傳統存儲或服務器網絡許多倍。而且Oracle的互連協議使用直接內存訪問（DMA），直接將數據從線纜轉移到數據庫緩存，沒有額外的數據拷貝，以確保極低的CPU開銷。Infiniband網絡具有 LAN網絡的靈活性和SAN的高效性，使用 InfiniBand網絡后，Oracle可確保網絡不會成為性能瓶頸，其也為 Oracle數據庫真正應用集群節點提供了高性能集群互連。

3.2.4 集中化、統一的云平臺管理

Oracle Exadata與 Oracle企業管理器 (EM)網格控制進行了集成，可輕松監視Exadata環境。在現有的 EM系統中安裝 Exadata插件后，可以監視Exadata Storage Server上的統計信息和活動，并將事件和警報發送給管理員。EM系統與Exadata集成的優勢介紹如下。

·監視 Oracle Exadata存儲；

·收集存儲配置和性能信息；

·根據閾值設置發出報警和警告；

·在歷史數據的基礎上提供豐富的現成量度和報表。

所有的功能用戶均期望可以配合使用 Oracle企業管理器和Exadata。用戶可以使用 EM界面輕松地管理Exadata環境和其他以往結合企業管理器使用的 Oracle數據庫環境。DBA可以使用熟悉的 EM界面來查看報表以確定 Exadata系統的狀況并管理Exadata存儲的配置。

4 數據庫PaaS云平臺帶來的運維和管理的轉變

4.1 數據庫PaaS云平臺的運維管理模式

從本質上來說，云計算并不是一種技術的革命，而是一種管理模式的革命。云計算的技術基礎，不論是服務器虛擬化、存儲虛擬化，還是平臺軟件級別的集群和資源控制，都是已經存在了若干年的技術。從技術手段上來說，這些技術手段短則出現了10年，長的在30年前就已經存在了 （如服務器虛擬化）。但是云計算之所以能對IT的建設和運維帶來新的創新，關鍵在于對整個IT架構的日常管理和運維帶來的革命性變更。將所有的資源虛擬化后，伴隨著動態可調的能力，大大加快了新應用建設在平臺層的建設速度，而且能按照實際的運行情況進行動態調整。

但是這種管理模式革命性的變更，也帶來了對應用/系統管理維護的新需求。傳統方式中，在大多數的實際情況下，應用軟件的開發商SI不僅僅是對自己的應用提供運維，而且也對其應用之下的平臺軟件/硬件進行主要的運維操作，并根據實際運行的情況，對用戶提出基礎架構擴容和調整的需求。在采用 PaaS提供數據庫云的方式下，之前的SI全部負責的方式必然不可行。因為SI不再負責包括基礎硬件和數據庫軟件的數據庫平臺的運維，而只是一個數據庫作為服務的消費者，必須要有第三方負責相應云平臺的運維。同時，由于實際的情況，SI往往會提出自己的數據庫服務需要的資源變更請求，對于這些資源變更請求的評估和批準，當然也應該由SI之外的人員/組織予以完成。簡單總結一下，在采用數據庫云平臺后，原來的SI和最終用戶的關系會演變成如下4方面的關系，如圖8所示。

首先引入的是SI的數據庫云平臺維護者，負責對數據庫云平臺的日常監控、安全管理等工作。而且需要由數據庫云平臺管理者負責對開發商提出的資源變更需求進行決策，判斷是否應當進行資源調整。數據庫云平臺的管理者也需要根據實際業務的情況和云平臺維護者給出的系統報告，主動地進行資源調整，以確保系統的資源利用率和各個應用的服務質量。

這樣的管理模式變革，對數據庫云平臺也提出了相應的技術要求。例如，必須有完整的監控手段，監控各個應用資源的使用情況，而且不僅僅是監控，還需要提供更高層次的診斷和優化工具，避免由于SI開發應用的低效率而導致的資源浪費，避免誰的應用越爛，誰就能分配更多資源的不良情況。

對于數據庫云平臺的維護者來說，也需要更高的技能提升，能在多租戶的情況下，從數據庫的運維上升到數據庫云的運維。對平臺維護者來說，也是一個全新的課題。

4.2 目前在數據庫PaaS云平臺上的運維管理實踐

基于廣東移動網絡運維部門數據庫系統多而雜的特點，在數據庫云平臺部署過程中，對云平臺的管理和運維也相應總結了一套實用的管理流程，其主要涵蓋了從部署云資源池、應用申請云平臺資源需求、評估和審批資源，到部署應用服務和所對應的計算和存儲資源、服務資源SLA管理和按需資源調度，再到最終應用退出和資源回收的一套完整過程。下面簡單舉例說明部分管理流程要點，如圖9所示。

圖8 原來的SI和最終用戶的關系

圖9 部分管理流程要點

4.2.1 創建資源服務池

首先基于Exadata構建廣東移動網絡運維的多個數據庫資源池，分為OLTP型應用資源池、OLAP型應用資源池、空閑資源池等，如圖10所示，將部分服務器劃分在各個對應的資源池內。

圖10 數據庫資源池分類

4.2.2 評估原有生產系統業務特點

對原有各個生產系統進行調研和評估，評估原有系統的硬件配置和系統容量，如圖11所示。對應用特點進行評估，評估業務特點和處理峰值。評估業務系統遷移到Exadata數據庫云平臺后，對所需的存儲和計算能力需求以及對應用的重要程度進行評估分類，以便在數據庫云平臺中進行資源控制和服務級別管理。

4.2.3 創建業務服務并配置對應分配的資源

將各個業務應用創建成數據庫應用服務，在所對應的資源池內進行部署，并按照各個數據庫應用服務的評估所需的資源進行初始資源劃分，如圖12所示。并按照各個應用服務服務的生產規律性周期頻度，進行規律性資源計劃定義。

5 現網應用效果對比

5.1 性能對比

經過實際測試，基于現網真實數據和應用，測試Exadata數據庫云平臺的多類應用(OLTP+OLAP)，性能提升從44倍到6 750倍。原來數小時的大作業類似于OLAP，目前只需要幾秒鐘完成，基本都提高了上千倍。原來大量循環+游標類似于OLTP的存儲過程也有44倍和127倍的提高，見表1。

5.2 系統擴展能力

對于Exadata的數據庫云平臺擴展能力測試，告警SQL5（CPU 高負載 SQL，SQL達 34 KB）從 1/4配（執行時間0:01:08）擴展到1/2配（執行時間0:00:31）時，可以明顯發現執行時間線性減少（從68 s到31 s），如圖13所示。

5.3 壓縮比

經過測試，用現網生產數據在Exadata數據庫云平臺中壓縮存儲，Exadata對兩個大表的壓縮率分別可達到7倍和10倍，見表2。

5.4數據庫云服務資源池和服務定義

配置兩個數據庫服務Service1、Service2，可以在數據庫云服務虛擬池內實現服務的動態擴展、回收和遷移。

建立ora.gmsp服務池，管理dm01db01、dm01db02兩個服務器的資源。Srvctl add srvpool–g ora.gmsp–l 0-u-1–i 0–n dm01db01,dm01db02也可以在Oracle企業管理器界面中添加服務器池。

圖11 原有生產系統評估示例

圖12 初始資源劃分

表1 實際測試結果

圖13 數據庫云平臺擴展能力測試

表2 壓縮比測試結果

添加dbfsdg_mount資源具體操作方法如下。

·在Oracle企業管理器界面中服務器集群dm01-cluster上的資源管理處添加資源。

·資源名:dbfsdg_mount。

·資源類型:local_resource。

·操作程序:代理文件和操作腳本。

5.5 服務資源分配

在數據庫云平臺內，可以按照業務優先級配置系統資源供給。能夠配置的資源包括業務的CPU、內存、并發會話數以及I/O優先級和吞吐量。

通過在Oracle企業管理器界面中定義資源計劃，可以基于多種條件將不同的會話劃分到多個資源組中，對不同的資源組分配不同的CPU資源，分配CPU資源可以基于CPU百分比，定義多個優先級進行分配。

5.5.1 對CPU的分配

在系統中定義了 OLTP_GROUP、OLAP_GROUP和OTHER_GROUP 3個資源組，根據需求，為不同的資源組分配不同的CPU比例。

·OLAP_GROUP：60%。

·OLTP_GROUP：20%。

·OTHER_GROUP：20%。

通過分配，可以保證資源組中的會話獲得所需的CPU資源，高優先級的會話獲得更多的資源。

5.5.2 對最大活動會話數的分配

通 過 定 義 OLTP_GROUP、OLAP_GROUP和OTHER_GROUP 3個資源組，對資源組中的用戶限制最大活動會話數。

·OLAP_GROUP：300。

·OLTP_GROUP：50。

·OTHER_GROUP：100。

資源組中的用戶的并發會話不能超過設定的上限，超過上限的會話創建請求會被放置在隊列中。

5.5.3 對I/O資源的分配

通過定義 OLTP_GROUP、OLAP_GROUP和OTHER_GROUP 3個資源組，對可使用的I/O帶寬和每秒鐘的I/O次數進行限制，保證高優先級的用戶獲得更快的I/O響應。

·OLAP_GROUP：每秒最高I/O帶寬使用10 000 MB，I/O次數上限為100 000次。

圖14 集中化管理和監控數據界面

·OLTP_GROUP：每秒最高I/O帶寬使用 100 MB，I/O次數不受限制。

·OTHER_GROUP：每秒最高I/O帶寬使用1 000 MB，I/O次數不受限制。

5.6 集中化管理和監控

通過云管理平臺監控系統運行情況，可查看主機、存儲、網絡、數據庫等基本信息，查看日志和告警信息等。

登錄Oracle企業管理器的管理界面，在目標主機中找到Exadata的主機，打開主機后在性能選項卡中可以看到 CPU、內存、磁盤I/O的使用率曲線，如圖14所示。

6 結束語

云計算給電信企業帶來了技術的創新，也帶來了管理的變革、支撐形式的挑戰和業務運營的機遇。隨著數據庫云平臺的逐漸成熟和落地，會看到更加靈活、快捷的應用的部署；更加低能耗、低成本的運營；更加簡單的維護和管理；更加容易實現的大規模系統建設甚至全國性集中化系統的建設，由此而帶來的是企業規模式效益、全網化的營銷和服務、統一和集中化的管理等價值，對電信企業的轉型起到關鍵的作用。所以進一步深入探索和實現低成本、大規模數據庫云計算技術，特別是與之配合的管理和運維問題，是下一步深化數據庫云計算技術的關鍵任務。