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數據庫云平臺的多／直ffi(0LTP+0LAP），性能提升從44倍到6 750倍。原來數小時的大作業類似于OLAP，目前只需要幾秒鐘完成，基本都提高了上千倍。原來大量循環+游標類似于OLTP的存儲過程也有“倍和127倍的提高，見表1。
表1 實際測試結果
5．2系統擴展能力
對于Exadata的數據庫云平臺擴展能力測試，告警SQL5(CPU高負載SQL，SQL達34 KB)從1／4配(執行時間0：01：08)擴展到1／2配(執行時間0：00：31)時，可以明顯發現執行時間線性減少(從68 8到31s)，如圖13所示。
圖11 原有生產系統評估實例
圖12 初始資源劃分
圖13 數據庫云平臺擴展能力測試
5．3壓縮比
經過測試，用現網生產數據在Exadata數據庫云平臺中壓縮存儲，Exadata對兩個大表的壓縮率分別可達到7倍和10倍，見表2。
表2 壓縮比測試結果
5．4數據庫云服務資源池和服務定義
配置兩個數據庫服務Servicel、Service2，可以在數據庫云服務虛擬池內實現服務的動態擴展、回收和遷移。建立ora．gmsp服務池，管理dm01db01、dm01db02兩個服務器的資源。Srvctl add srvpool—g ora．gmsp—10一u—1—i0一n dm01dbol。din01db02也可以在Oracle企業管理器界面中添加服務器池。
添加dbfsdg_mount資源具體操作方法如下。
·在Oracle企業管理器界面中服務器集群dm01一cluster上的資源管理處添加資源。
·資源名：dbfsdg_mount。
·資源類型：local—resource。
·操作程序：代理文件和操作腳本。
5．5服務資源分配
在數據庫云平臺內，可以按照業務優先級配置系統資源供給。能夠配置的資源包括業務的CPU、內存、并發會話數以及I／0優先級和吞吐量。
通過在Oracle企業管理器界面中定義資源計劃，可以基于多種條件將不同的會話劃分到多個資源組中，對不同的資源組分配不同的CPU資源，分配CPU資源可以基于CPU百分比，定義多個優先級進行分配。
5．5．1對CPU的分配
在系統中定義了0LTP-GROUP、OLAP__GROUP和OTHER GROUP 3個資源組，根據需求，為不同的資源組分配不同的CPU比例。
·OLAP GROUP：60％。
·0U11P_GROUP：20％。
·OTHER_GROUP：20％。
通過分配，可以保證資源組中的會話獲得所需的CPU資源，高優先級的會話獲得更多的資源。
5．5．2對最大活動會話數的分配
通過定義O皿GROUP、OLAP_GROUP和OTHERGROUP3個資源組，對資源組中的用戶限制最大活動會話數。
·OLAP_GROUP：300。
·OLTP_GROUP：50。
·OTHER_GROUP：100。
資源組中的用戶的并發會話不能超過設定的上限，超過上限的會話創建請求會被放置在隊列中。
5．5．3對I／O資源的分配
通過定義OLTP_GROUP、OLAP_GROUP和OTHER_GROUP 3個資源組，對可使用的I／0帶寬和每秒鐘的I／0次數進行限制，保證高優先級的用戶獲得更快的I／O響應。
·OLAP_GROUP：每秒最高I／O帶寬使用10 000 MB，I／0次數上限為100 000次。
·0LTP—GROUP：每秒最高ⅣO帶寬使用100 MB，I／0次數不受限制。
·OTHER—GROUP：每秒最高I／0帶寬使用1 000MB，I／O次數不受限制。
5．6集中化管理和監控
通過云管理平臺監控系統運行情況，可查看主機、存儲、網絡、數據庫等基本信息，查看日志和告警信息等。
登錄Oracle企業管理器的管理界面，在目標主機中找到Exadata的主機，打開主機后在性能選項卡中可以看到CPU、內存、磁盤I／O的使用率曲線，如圖14所示。
圖14 集中化管理和監控數據界面
6 結束語
云計算給電信企業帶來了技術的創新。也帶來了管理的變革、支撐形式的挑戰和業務運營的機遇。隨著數據庫云平臺的逐漸成熟和落地，會看到更加靈活、快捷的應用的部署；更加低能耗、低成本的運營；更加簡單的維護和管理；更加容易實現的大規模系統建設甚至全國性集中化系統的建設，由此而帶來的是企業規模式效益、全網化的營銷和服務、統一和集中化的管理等價值，對電信企業的轉型起到關鍵的作用。所以進一步深人探索和實現低成本、大規模數據庫云計算技術，特別是與之配合的管理和運維問題，是下一步深化數據庫云計算技術的關鍵任務。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：企業級數據庫云平臺的建設與運維方案(下)
相關文章
