金融行業(yè)開(kāi)發(fā)測(cè)試云管平臺(tái)架構(gòu)方案設(shè)計(jì)

1、 金融行業(yè)開(kāi)發(fā)測(cè)試云管平臺(tái)架構(gòu)方案設(shè)計(jì) 前言隨著信息技術(shù)的飛速發(fā)展，云計(jì)算技術(shù)的應(yīng)用也越來(lái)越廣泛。云計(jì)算為企業(yè)帶來(lái)了資源快速的交付能力、強(qiáng)大的敏捷性、靈活的橫縱向擴(kuò)展性以及高標(biāo)準(zhǔn)的部署規(guī)范性。這些優(yōu)點(diǎn)在開(kāi)發(fā)測(cè)試云計(jì)算的運(yùn)用當(dāng)中，表現(xiàn)地尤為突出。云計(jì)算平臺(tái)不僅僅是一個(gè)統(tǒng)一資源管控平臺(tái)，更重要的是一個(gè)IT服務(wù)平臺(tái)，它將資源抽象化和服務(wù)化，極大簡(jiǎn)化了企業(yè)用戶的管理和使用，而在云計(jì)算中最核心的就是云管平臺(tái)，一個(gè)貼切企業(yè)實(shí)際需求的云管平臺(tái)，能夠強(qiáng)化企業(yè)IT資源的管理能力，提升企業(yè)IT資源利用率，滿足企業(yè)對(duì)大規(guī)模計(jì)算能力的需求，從而進(jìn)一步推動(dòng)企業(yè)業(yè)務(wù)的發(fā)展。本文旨在探討如何更好地設(shè)計(jì)金融行業(yè)開(kāi)發(fā)測(cè)試云管平

2、臺(tái)，包括云管平臺(tái)的需求、定位和設(shè)計(jì)方案。開(kāi)發(fā)測(cè)試云的需求在金融行業(yè)中，對(duì)于開(kāi)發(fā)測(cè)試云，通常有以下幾點(diǎn)需求：1.資源整合、大幅提高資源利用率在開(kāi)發(fā)測(cè)試環(huán)境，由于環(huán)境復(fù)雜性、成本、歷史等原因，開(kāi)發(fā)測(cè)試環(huán)境的資源孤島現(xiàn)象十分常見(jiàn)，資源利用率低但卻依舊無(wú)可用資源，為了擺脫該痛點(diǎn)，企業(yè)都已經(jīng)開(kāi)始利用虛擬化技術(shù)，進(jìn)行資源整合和資源共享，擺脫開(kāi)發(fā)測(cè)試資源孤島格局。另外，資源回收也是企業(yè)一大痛點(diǎn)，傳統(tǒng)環(huán)境資源回收過(guò)程艱難，不徹底，也沒(méi)有資源生命周期的概念。這是開(kāi)發(fā)測(cè)試云管平臺(tái)需要考量的要點(diǎn)之一。2.為敏捷開(kāi)發(fā)提供快速部署的支撐隨著金融行業(yè)業(yè)務(wù)的互聯(lián)網(wǎng)化，功能的快速開(kāi)發(fā)、測(cè)試和上線變得越來(lái)越重要，而敏捷開(kāi)發(fā)和測(cè)

3、試對(duì)資源的需求是極快速的，這里的資源不僅僅包括計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)，還包括各類基礎(chǔ)軟件資源、中間件資源和數(shù)據(jù)庫(kù)資源等，所以需要利用云計(jì)算快速、自動(dòng)化軟硬件服務(wù)編排的功能，提高敏捷開(kāi)發(fā)的能力，大幅縮短開(kāi)發(fā)測(cè)試環(huán)境部署的時(shí)間。這是開(kāi)發(fā)測(cè)試云管平臺(tái)需要考量的要點(diǎn)之二。3.資源部署策略多樣性云計(jì)算資源池可提供各類不同平臺(tái)、不同性能、不同廠商的資源，為多樣性的開(kāi)發(fā)測(cè)試提供選擇，所以資源的部署策略同樣需要多樣性，能夠根據(jù)企業(yè)用戶設(shè)定的不同策略，動(dòng)態(tài)自動(dòng)化的部署到不同的資源當(dāng)中。同樣，這些策略的設(shè)定也需簡(jiǎn)易和便捷，無(wú)需用戶了解過(guò)多的底層實(shí)現(xiàn)。這是開(kāi)發(fā)測(cè)試云管平臺(tái)需要考量的要點(diǎn)之三。4.資源調(diào)配靈活性資源的調(diào)配不

4、局限，需要具有靈活性和動(dòng)態(tài)性，靈活性方面無(wú)論是計(jì)算資源、存儲(chǔ)資源還是軟件資源，無(wú)論是Scale Up還是Scale Out，甚至需要云管平臺(tái)能夠?qū)油獠康墓性瀑Y源，動(dòng)態(tài)調(diào)配私有云和公有云的資源，實(shí)現(xiàn)混合云的工作負(fù)載模式。動(dòng)態(tài)性方面云管平臺(tái)需要能夠?qū)崟r(shí)監(jiān)控底層資源的使用情況，在觸發(fā)動(dòng)態(tài)調(diào)配閥值時(shí)，通知用戶或者自動(dòng)進(jìn)行資源的在線遷移或者擴(kuò)展。這是開(kāi)發(fā)測(cè)試云管平臺(tái)需要考量的要點(diǎn)之四。5.保持開(kāi)發(fā)測(cè)試與生產(chǎn)的統(tǒng)一規(guī)范傳統(tǒng)開(kāi)發(fā)測(cè)試環(huán)境和生產(chǎn)環(huán)境部署不規(guī)范，不統(tǒng)一，造成了很多問(wèn)題和痛苦，即使制定了相關(guān)規(guī)范性文檔或者實(shí)施工藝，但由于人和流程等的因素，往往落地十分困難，形成一紙空文。而在云計(jì)算中，由于云管平

5、臺(tái)的存在，可以將標(biāo)準(zhǔn)的模版、軟件和配置規(guī)范可以介質(zhì)的形式存放于云倉(cāng)庫(kù)，生產(chǎn)和測(cè)試環(huán)境只需保持云倉(cāng)庫(kù)的同步即可，這樣一來(lái)更易于保持生產(chǎn)與開(kāi)發(fā)測(cè)試環(huán)境的統(tǒng)一和規(guī)范，二來(lái)由于這些規(guī)范隨資源部署時(shí)自動(dòng)化落地，規(guī)避了人為和流程的因素。這是開(kāi)發(fā)測(cè)試云管平臺(tái)需要考量的要點(diǎn)之五。6.自動(dòng)化運(yùn)維、監(jiān)控和流程的集成相較于生產(chǎn)環(huán)境，開(kāi)發(fā)測(cè)試環(huán)境的自動(dòng)化運(yùn)維和監(jiān)控往往就不大重視，然而實(shí)際問(wèn)題卻是開(kāi)發(fā)測(cè)試環(huán)境經(jīng)常莫名奇妙出現(xiàn)各類問(wèn)題，各個(gè)節(jié)點(diǎn)檢查后才發(fā)現(xiàn)是非常簡(jiǎn)單的原因造成的，這時(shí)簡(jiǎn)單的監(jiān)控也變得需要；另外由于開(kāi)發(fā)測(cè)試環(huán)境節(jié)點(diǎn)數(shù)規(guī)模十分龐大，也不可能指定大量專門的運(yùn)維團(tuán)隊(duì)去維護(hù)開(kāi)發(fā)測(cè)試環(huán)境，所以開(kāi)發(fā)測(cè)試環(huán)境的自動(dòng)化運(yùn)維

6、也變得需要；最后如何實(shí)現(xiàn)開(kāi)發(fā)、測(cè)試和生產(chǎn)運(yùn)維流程一體化也是需要考量點(diǎn)之一，讓整個(gè)IT流程在各個(gè)階段都運(yùn)轉(zhuǎn)和串聯(lián)起來(lái)。所以開(kāi)發(fā)測(cè)試環(huán)境的云管平臺(tái)需要合理的集成自動(dòng)化運(yùn)維、監(jiān)控和流程平臺(tái)。這是開(kāi)發(fā)測(cè)試云管平臺(tái)需要考量的要點(diǎn)之六。云管平臺(tái)的定位說(shuō)完了云管平臺(tái)的需求，再來(lái)說(shuō)說(shuō)云管平臺(tái)的定位。由于云計(jì)算的層次和概念比較多，各個(gè)行業(yè)的資源使用情況也不一樣，加上各類云計(jì)算廠商的宣傳和用詞，很容易造成用戶的概念混淆或者疑惑。我們先來(lái)看看目前常見(jiàn)的云計(jì)算體系層次架構(gòu)：1.商用X86云商用X86云主要是Vmware技術(shù)為主要代表，VCenter虛擬化管理平臺(tái)相當(dāng)于資源管理層，Vrealize Automation

7、則為云管理平臺(tái)層，不僅提供API功能的自服務(wù)和統(tǒng)一服務(wù)目錄，也能支持不同供應(yīng)商的多套私有云和公有云，還支持對(duì)容器的管理等。該云管平臺(tái)的特色是和Vmware的底層技術(shù)緊密結(jié)合，通過(guò)抽象化底層實(shí)現(xiàn)技術(shù)，同時(shí)提供可視化服務(wù)和可拖放的設(shè)計(jì)畫(huà)布，將預(yù)構(gòu)建的組件組合為各種應(yīng)用。2.開(kāi)源X86云開(kāi)源X86云主要以O(shè)penStack為框架，利用OpenStack的各類組件對(duì)接不同的資源，各廠商在公版OpenStack的基礎(chǔ)之上，開(kāi)發(fā)各具特色的云管平臺(tái)，包括統(tǒng)一資源層和服務(wù)抽象層，資源層的實(shí)現(xiàn)需要在公版OpenStack各組件上進(jìn)行改良和優(yōu)化，而服務(wù)抽象層的設(shè)計(jì)完全就是各組件的API的調(diào)用和抽象，將不同的IT服

8、務(wù)、編排策略、動(dòng)態(tài)優(yōu)化策略等翻譯成不同組件的API調(diào)用組合，另外還需和其他像自動(dòng)化運(yùn)維和監(jiān)控等工具相結(jié)合，這就完全考驗(yàn)各廠商或者用戶企業(yè)的開(kāi)發(fā)實(shí)力和對(duì)云管平臺(tái)的理解能力。3.Power云Power云很簡(jiǎn)單，以IBM的PowerVC為目前的最佳選擇，PowerVC提供兩種版本，一種是PowerVC Standard Edition，提供基本的虛擬化資源管理能力，另一種是Cloud PowerVC Manager，在Standard Edition之上還提供了自服務(wù)功能和簡(jiǎn)單流程審批功能，能夠定義各類計(jì)算模板和存儲(chǔ)模板，自動(dòng)化按照模板進(jìn)行計(jì)算資源和存儲(chǔ)資源的編排。此外，還提供了DRO動(dòng)態(tài)資源優(yōu)化功

9、能，能夠?qū)崟r(shí)監(jiān)控資源的使用情況，按照設(shè)定，提示或者自動(dòng)化在不同計(jì)算節(jié)點(diǎn)上均衡工作負(fù)載。最后，PowerVC和Power的特性緊密結(jié)合是最大特色，比如Remote Restart、LPM、EnterprisePool和PowerHA等等，利用該云管平臺(tái)能夠?qū)崿F(xiàn)一整套完善的Power高可用體系架構(gòu)。4.Power和X86共存云這是金融行業(yè)云計(jì)算體系最常見(jiàn)的架構(gòu)體系，不像純互聯(lián)網(wǎng)企業(yè)那樣，完全是X86，而由于金融行業(yè)的特殊性，以追求最大的穩(wěn)定可靠性為第一目標(biāo)，所以金融行業(yè)的企業(yè)目前Power計(jì)算資源是必不可少的，至少在今后很長(zhǎng)一段時(shí)間Power和X86將共存，所以其云計(jì)算體系架構(gòu)是需要考慮如何實(shí)現(xiàn)不

10、同平臺(tái)異構(gòu)資源的共存，同時(shí)還要考慮純物理計(jì)算資源的接管。相較于開(kāi)源X86云，這類異構(gòu)資源的統(tǒng)一管理，實(shí)現(xiàn)技術(shù)為Driver的集成，將PowerVC Adapter、Vcenter甚至Z/VM的Driver集成至云管平臺(tái)的統(tǒng)一資源層，通過(guò)Driver的API間接管理和調(diào)度Power和Vmware X86的資源池；至于純物理計(jì)算資源的接管，則是用到了OpenStack裸金屬Ironic組件，它提供了一系列常用的Baremetal Server的Driver，并且提供了插件的機(jī)制讓二次開(kāi)發(fā)的廠商可以開(kāi)發(fā)一些其他Baremetal Server的Driver嵌入其中。最后，對(duì)于公有云或者容器云，也是云

11、管平臺(tái)通過(guò)其提供的Restfull API進(jìn)行對(duì)接。綜上四種架構(gòu)，可以很清楚看到，云計(jì)算體系應(yīng)該包含三層或者四層：資源池層，虛擬化管理平臺(tái)層，云管平臺(tái)資源層和云管平臺(tái)服務(wù)層。資源池層，包括各類計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)資源，這個(gè)資源可以是做了虛擬化技術(shù)的，也可以是沒(méi)做虛擬化技術(shù)的物理機(jī)；虛擬化管理平臺(tái)層對(duì)各類同構(gòu)的底層虛擬化資源池統(tǒng)一管理；云管平臺(tái)資源層實(shí)現(xiàn)對(duì)所有異構(gòu)的資源的統(tǒng)一管理；云管平臺(tái)服務(wù)層實(shí)現(xiàn)自服務(wù)界面，將服務(wù)的底層資源實(shí)現(xiàn)、部署策略和動(dòng)態(tài)調(diào)配實(shí)現(xiàn)抽象化，集成各類運(yùn)維、管理和流程的工具等。實(shí)際上，廣義上來(lái)說(shuō)，云管平臺(tái)應(yīng)該包含統(tǒng)一資源層和服務(wù)層，狹義的云管平臺(tái)只是服務(wù)層，這兩個(gè)層次可以在一套軟件

12、中實(shí)現(xiàn)，像輕量級(jí)IaaS Power云-Cloud PowerVC Manager、其他三方（如EasyStack、東軟Saca、云宏和SAP等）云管平臺(tái)，也可以多套軟件實(shí)現(xiàn)，軟件和軟件間有API接口實(shí)現(xiàn)對(duì)接，像Cloud Manager+ICO的組合、StartCloud+SelectStack的組合、VCenter+Vrealize的組合或者異構(gòu)軟件的組合（如StartCloud+Vrealize/ICO/EasyStack）等等。這些商用云管平臺(tái)的例子告訴我們，統(tǒng)一資源層和服務(wù)層是緊密不可分割的，所以我們?cè)谠O(shè)計(jì)云管平臺(tái)時(shí)的定位應(yīng)該要在廣義的角度去統(tǒng)一設(shè)計(jì)，而不僅僅是從服務(wù)層的角度。云管平

13、臺(tái)的架構(gòu)設(shè)計(jì)有了前面開(kāi)發(fā)測(cè)試云的需求和云管平臺(tái)定位的簡(jiǎn)單介紹，現(xiàn)在正式進(jìn)入開(kāi)發(fā)測(cè)試云管平臺(tái)的設(shè)計(jì)階段，主要包括三個(gè)部分：統(tǒng)一資源層的設(shè)計(jì)、服務(wù)抽象層的設(shè)計(jì)和運(yùn)維管理集成的設(shè)計(jì)。邏輯架構(gòu)圖如下：1.統(tǒng)一資源層的設(shè)計(jì)云管平臺(tái)的統(tǒng)一資源層并非是資源的直接提供者，而是資源的管控者或者調(diào)度者，對(duì)上提供API，供服務(wù)抽象層調(diào)用，對(duì)下集成資源的Driver，承上啟下，作為云計(jì)算技術(shù)的具體實(shí)現(xiàn)層，統(tǒng)一資源層的設(shè)計(jì)需要有“平臺(tái)”、“分布式”和“動(dòng)態(tài)”的設(shè)計(jì)理念。一是資源層能夠提供一個(gè)資源適配平臺(tái)，能夠適配各類計(jì)算資源（異構(gòu)X86和Power虛擬化、物理機(jī)、公有云和容器云），各類網(wǎng)絡(luò)資源（網(wǎng)絡(luò)類型：local、F

14、lat、VLAN、VXLAN、GRE；網(wǎng)絡(luò)機(jī)制：LinuxBridge、Openvswitch；網(wǎng)絡(luò)服務(wù)：Router、LoadBalance、Firewall、DHCP等），各類存儲(chǔ)資源（LVM，NFS，Ceph，GlusterFS，以及EMC和IBM等商業(yè)存儲(chǔ)系統(tǒng)），各類軟件資源（中間件、工具、數(shù)據(jù)庫(kù)和應(yīng)用等）；二是資源層的各組件能夠按照一定細(xì)粒度分布到不同的控制節(jié)點(diǎn)中，這樣可以提高性能和伸縮性，避免隨著資源節(jié)點(diǎn)數(shù)的增加，造成的瓶頸；三是資源層的編排是動(dòng)態(tài)和自動(dòng)化的，在資源層按照過(guò)濾規(guī)則、策略或者資源模板進(jìn)行設(shè)定后，部署則按照該策略模型就行自動(dòng)化的編排，并且可以和監(jiān)控組件（如OpenSta

15、ck的Ceilometer）相結(jié)合，實(shí)現(xiàn)動(dòng)態(tài)的遷移、伸縮和擴(kuò)展資源。整體資源層示意圖如下：“平臺(tái)”理念：（1）計(jì)算資源OpenStack作為開(kāi)放的Infrastracture as a Service云操作系統(tǒng)，支持業(yè)界各種優(yōu)秀的技術(shù)，這些技術(shù)可能是開(kāi)源免費(fèi)的，也可能是商業(yè)收費(fèi)的。 這種開(kāi)放的架構(gòu)使得OpenStack 保持技術(shù)上的先進(jìn)性，具有很強(qiáng)的競(jìng)爭(zhēng)力，同時(shí)又不會(huì)造成廠商鎖定（Lock-in）。那OpenStack 的這種開(kāi)放性體現(xiàn)在哪里呢？一個(gè)重要的方面就是采用基于Driver的平臺(tái)框架。先來(lái)看Nova組件：計(jì)算資源分兩塊，一塊是虛擬化資源，一塊是物理資源，虛擬化資源又分直接虛擬化資源和

16、間接虛擬化資源，先說(shuō)直接虛擬化資源，也就是云管平臺(tái)資源層直接對(duì)接虛擬化資源，但是現(xiàn)在市面上有這么多Hypervisor，資源層的Nova又是如何與他們配合的呢？答案是通過(guò)Nova-API調(diào)用Nova-compute子組件，Nova-compute子組件為Driver 架構(gòu)，nova-compute 為這些 Hypervisor 定義了統(tǒng)一的接口，Hypervisor只需要實(shí)現(xiàn)這些接口，就可以Driver 的形式即插即用到OpenStack Nova系統(tǒng)中。下面是Nova Driver的架構(gòu)示意圖，這時(shí)的Nova-compute存在于物理計(jì)算節(jié)點(diǎn)中：再說(shuō)間接虛擬化資源，云管平臺(tái)資源層的Nova-

17、compute集成了虛擬化管理平臺(tái)的Driver，間接通過(guò)虛擬化管理平臺(tái)管理和調(diào)度計(jì)算資源，如PowerVC、Vcenter和Z/VM就是這樣納入云管平臺(tái)的。但是這種方式也有一個(gè)弊端，雖然通過(guò)Driver可以調(diào)用虛擬化管理平臺(tái)的API獲得資源信息和進(jìn)行操作，但是由于不直接跟Hypervisor通信，一些底層的虛擬化操作是無(wú)法被云管接管的，特別是一些特性化的功能，另外API也無(wú)法提供所有的操作，依舊需要去虛擬化管理平臺(tái)進(jìn)行操作，此外，虛擬化管理平臺(tái)本身也具備一些編排策略和動(dòng)態(tài)優(yōu)化規(guī)則，而云管平臺(tái)資源層也設(shè)計(jì)了相應(yīng)的策略和規(guī)則，間接的接管方式需要考慮這些功能是否可以通過(guò)API往統(tǒng)一資源層上集成，再

18、往服務(wù)抽象層上集成。最后是物理資源，Nova-API調(diào)用資源層的Nova-compute，Nova-compute再調(diào)用Ironic的API來(lái)實(shí)現(xiàn)對(duì)物理資源的管理和控制，可以理解為Nova-compute集成了Ironic的Driver，Ironic可以看成一個(gè)Hypervisor Driver來(lái)給Nova來(lái)用。再者Ironic中也集成了許多Baremetal Server的Driver，并提供了插件的機(jī)制讓二次開(kāi)發(fā)的廠商可以開(kāi)發(fā)一些其他Baremetal Server的Driver嵌入其中。（2）存儲(chǔ)資源OpenStack的存儲(chǔ)組件為Cinder，存儲(chǔ)節(jié)點(diǎn)支持多種Volume Provide

19、r，包括LVM, NFS, Ceph, GlusterFS，以及EMC, IBM等商業(yè)存儲(chǔ)系統(tǒng)。Cinder-volume為這些Volume Provider定義了統(tǒng)一的 Driver 接口，Volume Provider只需要實(shí)現(xiàn)這些接口，就可以Driver的形式即插即用到OpenStack中。下面是Cinder Driver的架構(gòu)示意圖：（3）網(wǎng)絡(luò)資源Neutron的核心組件包括Core Plugin和Service Plugin，Core Plugin負(fù)責(zé)管理和維護(hù) Neutron的Network, Subnet和Port的狀態(tài)信息，這些信息是全局的，只需要也只能由一個(gè)Core Plug

20、in管理。只使用一個(gè)Core Plugin本身沒(méi)有問(wèn)題。但問(wèn)題在于傳統(tǒng)的Core Plugin 與Core Plugin Agent是一一對(duì)應(yīng)的。也就是說(shuō)，如果選擇了Linux Bridge Plugin，那么 Linux Bridge Agent將是唯一選擇，就必須在OpenStack的所有節(jié)點(diǎn)上使用Linux Bridge作為虛擬交換機(jī)（即Network Provider）。同樣的，如果選擇Open Vswitch Plugin，所有節(jié)點(diǎn)上只能使用Open Vswitch，而不能使用其他的Network Provider。此外，所有傳統(tǒng)的 Core Plugin都需要編寫(xiě)大量重復(fù)和類似的數(shù)

21、據(jù)庫(kù)訪問(wèn)的代碼，大大增加了Plugin開(kāi)發(fā)和維護(hù)的工作量。到了OpenStack Havana版本時(shí)，實(shí)現(xiàn)了一個(gè)新的Core Plugin，即ML2，ML2作為新一代的Core Plugin，提供了一個(gè)框架，允許在OpenStack網(wǎng)絡(luò)中同時(shí)使用多種Layer 2網(wǎng)絡(luò)技術(shù)，不同的計(jì)算節(jié)點(diǎn)可以使用不同的網(wǎng)絡(luò)實(shí)現(xiàn)機(jī)制。如下圖所示，采用ML2 Plugin 后，可以在不同節(jié)點(diǎn)上分別部署Linux Bridge Agent, Open Vswitch Agent, Hyper-v Agent 以及其他第三方Agent。 ML2不但支持異構(gòu)部署方案，同時(shí)能夠與現(xiàn)有的Agent無(wú)縫集成：以前用的Agent

22、不需要變，只需要將Neutron server上的傳統(tǒng)Core plugin替換為ML2。 有了ML2，要支持新的Network Provider就變得簡(jiǎn)單多了：無(wú)需從頭開(kāi)發(fā)Core Plugin，只需要開(kāi)發(fā)相應(yīng)的Mechanism Driver，大大減少了要編寫(xiě)和維護(hù)的代碼。（4）軟件資源軟件也作為一種資源存在于云管的資源層，軟件資源的實(shí)現(xiàn)有多種方式，一是最簡(jiǎn)單的鏡像模板實(shí)現(xiàn)，通過(guò)制作安裝了特定軟件資源的虛擬機(jī)，再捕獲為鏡像模板，存在鏡像倉(cāng)庫(kù)，部署時(shí)克隆一份；二是通過(guò)OpenStack HEAT組件實(shí)現(xiàn)，OpenStack Heat是一個(gè)基于模板來(lái)編排復(fù)合云應(yīng)用的服務(wù)模板，它的使用簡(jiǎn)化了復(fù)雜

23、基礎(chǔ)設(shè)施，服務(wù)和應(yīng)用的定義和部署。Heat模板支持豐富的資源類型，實(shí)現(xiàn)了對(duì)操作系統(tǒng)、應(yīng)用、中間件、框架和工具等的自動(dòng)化安裝和配置，規(guī)范了軟件資源的部署。OpenStack Heat提供四種軟件資源編排方式：Heat對(duì)軟件配置和部署的編排；Heat對(duì)負(fù)載均衡的編排；Heat對(duì)資源自動(dòng)伸縮的編排；Heat和配置管理工具集成。云管平臺(tái)在設(shè)計(jì)時(shí)，在服務(wù)抽象層存放編排的腳本，服務(wù)層在進(jìn)行翻譯時(shí)，會(huì)將編排的腳本加載至資源層的OpenStack Heat組件中，在其他組件完成硬件資源的部署后，OpenStack Heat運(yùn)行編排腳本，實(shí)現(xiàn)軟件資源的部署；三是通過(guò)容器編排實(shí)現(xiàn)，服務(wù)層將需求翻譯成資源層的API

24、，再通過(guò)云管平臺(tái)的資源層API調(diào)度容器云的編排引擎（Docker Swarm、Kubernetes和Mesos），間接實(shí)現(xiàn)容器軟件資源部署；四是通過(guò)OpenStack的特殊組件實(shí)現(xiàn)特殊軟件服務(wù)，如OpenStack的Trove組件可以實(shí)現(xiàn)DBaaS，OpenStack的Sahara組件可以實(shí)現(xiàn)HadoopaaS等。綜上，在設(shè)計(jì)云管平臺(tái)資源層時(shí)，要以“平臺(tái)”的理念去長(zhǎng)遠(yuǎn)規(guī)劃，保證云管平臺(tái)資源管理的統(tǒng)一性和可擴(kuò)展性?！胺植际健崩砟睿篛penStack的開(kāi)放性除了Driver框架下的平臺(tái)特性，還在于分布式的特性。所有組件既可以采用all-in-one的方式存在一個(gè)控制節(jié)點(diǎn)中，各個(gè)組件也可以廣泛分布于

25、各個(gè)不同的控制節(jié)點(diǎn)中，只需保證節(jié)點(diǎn)間的通信即可；不僅如此，每種組件中的子組件也可存在多個(gè)，進(jìn)行分布式部署，通過(guò)LoadBlance實(shí)現(xiàn)負(fù)載均衡；另外，對(duì)于all-in-one架構(gòu)的控制節(jié)點(diǎn)，也可按照不同功能、分區(qū)甚至數(shù)據(jù)中心進(jìn)行區(qū)分，組成多個(gè)全套的控制節(jié)點(diǎn)，這多個(gè)控制節(jié)點(diǎn)通過(guò)將Keystone認(rèn)證信息和EndPoint鏈接注入至其中一個(gè)主控制節(jié)點(diǎn)當(dāng)中，實(shí)現(xiàn)在該主控制節(jié)點(diǎn)統(tǒng)管所有資源，實(shí)際上部署卻是分布式的，互不相干的。（1）資源層控制節(jié)點(diǎn)的組件all-in-one云管平臺(tái)資源層設(shè)計(jì)為所有OpenStack組件都集中在一個(gè)控制節(jié)點(diǎn)中，適用于計(jì)算節(jié)點(diǎn)和存儲(chǔ)節(jié)點(diǎn)較少的場(chǎng)景，并且并發(fā)部署和管理的資源個(gè)

26、數(shù)不宜太多。另外，由于只有一個(gè)控制節(jié)點(diǎn)，該節(jié)點(diǎn)的高可用也需要考慮，尤其是控制節(jié)點(diǎn)中的數(shù)據(jù)庫(kù)，用數(shù)據(jù)庫(kù)復(fù)制技術(shù)也可，還可以用雙機(jī)軟件，搭建Linux操作系統(tǒng)的雙機(jī)實(shí)現(xiàn)高可用，如Keepalive、TSA或者Pacemaker等。（2）組件或者子組件分布于不同控制節(jié)點(diǎn)云管平臺(tái)資源層設(shè)計(jì)為所有不同的組件和子組件均衡分布于不同的控制節(jié)點(diǎn)當(dāng)中，如下圖所示為資源層架構(gòu)樣例，相同組件的控制節(jié)點(diǎn)通過(guò)應(yīng)用負(fù)載節(jié)點(diǎn)實(shí)現(xiàn)負(fù)載均衡（如HAProxy），實(shí)現(xiàn)ACTIVE-ACTIVE；RabbitMQ的消息控制節(jié)點(diǎn)則可通過(guò)自身的集群實(shí)現(xiàn)ACTIVE-ACTIVE，所有組件均通過(guò)RabbitMQ實(shí)現(xiàn)異步通信，同時(shí)為保證負(fù)

27、載均衡和自動(dòng)切換，組件配置了RabbitMQ的集群節(jié)點(diǎn)列表。數(shù)據(jù)庫(kù)節(jié)點(diǎn)間可通過(guò)高可用軟件+數(shù)據(jù)庫(kù)復(fù)制技術(shù)實(shí)現(xiàn)ACTIVE-STANDBY，所有數(shù)據(jù)庫(kù)的訪問(wèn)請(qǐng)求均通過(guò)虛擬服務(wù)IP實(shí)現(xiàn)。不僅如此，每個(gè)控制節(jié)點(diǎn)當(dāng)中的子組件設(shè)計(jì)也可以按照“分布式”的理念進(jìn)行設(shè)計(jì)，如下圖所示，同樣是多個(gè)相同的子組件通過(guò)HAProxy實(shí)現(xiàn)負(fù)載均衡，組件內(nèi)部的不同子組件間也均通過(guò)RabbitMQ集群進(jìn)行異步的通信。整個(gè)架構(gòu)有幾下優(yōu)點(diǎn)：A.當(dāng)計(jì)算資源不夠了無(wú)法創(chuàng)建虛機(jī)時(shí)，可以增加計(jì)算節(jié)點(diǎn)或者存儲(chǔ)節(jié)點(diǎn)（增加Nova-Compute、Neutron-Agent和Cinder-Provider）。B.當(dāng)客戶的請(qǐng)求量太大調(diào)度不過(guò)來(lái)時(shí)

28、，可以增加Scheduler或者直接增加控制節(jié)點(diǎn)。C.通過(guò)消息組件RabbitMQ的異步通信實(shí)現(xiàn)調(diào)用，一是可以解耦各子組件和組件，他們不需要知道其他組件在哪里運(yùn)行，只需要發(fā)送消息給消息組件就能完成調(diào)用。二是提高了性能，異步調(diào)用使得調(diào)用者無(wú)需等待結(jié)果返回。這樣可以繼續(xù)執(zhí)行更多的工作，提高系統(tǒng)總的吞吐量。三是提高伸縮性，子組件和組件可以根據(jù)需要進(jìn)行擴(kuò)展，啟動(dòng)更多的控制節(jié)點(diǎn)處理更多的請(qǐng)求，在提高可用性的同時(shí)也提高了整個(gè)系統(tǒng)的伸縮性。而且這種變化不會(huì)影響到其他組件，也就是說(shuō)變化對(duì)別人是透明的。所以，該資源層的架構(gòu)非常適合大規(guī)模和超大規(guī)模的云計(jì)算。（3）多個(gè)all-in-one的控制節(jié)點(diǎn)功能分區(qū)云管平臺(tái)

29、資源層的單個(gè)控制節(jié)點(diǎn)五臟俱全，包含了所需的所有組件，但每個(gè)控制節(jié)點(diǎn)的用途不一樣，比如每個(gè)網(wǎng)絡(luò)安全分區(qū)一個(gè)控制節(jié)點(diǎn)或者Power平臺(tái)一個(gè)或多個(gè)控制節(jié)點(diǎn)，Vmware X86一個(gè)或多個(gè)控制節(jié)點(diǎn)，然后開(kāi)源X86一個(gè)或多個(gè)控制節(jié)點(diǎn)，然后再搭建一個(gè)主控制節(jié)點(diǎn)，通過(guò)繼承其他控制節(jié)點(diǎn)的KeyStone和EndPoint實(shí)現(xiàn)資源的接管，在主控制節(jié)點(diǎn)的Dashboard上通過(guò)切換不同Region實(shí)現(xiàn)管理的切換。通常商用私有云管平臺(tái)喜歡采用這種架構(gòu)，因?yàn)樯逃卯a(chǎn)品的軟件會(huì)做得比較全，按照它的設(shè)計(jì)理念，面面俱到。但是這樣如果部署在一個(gè)控制節(jié)點(diǎn)上，在資源規(guī)模比較大的情況下，不可避免地會(huì)產(chǎn)生性能瓶頸，可靠性也存在考驗(yàn)。如

30、果按照不同功能進(jìn)行分區(qū)的方式，則能起到立竿見(jiàn)影的效果，同時(shí)也可以實(shí)現(xiàn)統(tǒng)一管理的效果。比如下面商用私有云的架構(gòu)（IBM Cloud Manager+IBM Cloud Orchestrator），不同功能的ICM控制節(jié)點(diǎn)分別管理不同的資源池，最后在邏輯上從屬于主ICM，主ICM設(shè)計(jì)為高可用集群架構(gòu)，其中的部分組件則采用了ACTIVE-ACTIVE的方式，均衡負(fù)載請(qǐng)求，實(shí)際上這個(gè)集群架構(gòu)則為第二種架構(gòu)模型，相當(dāng)于在這個(gè)架構(gòu)模型之上，再來(lái)了一層控制節(jié)點(diǎn)，增加了一層深度。和第二種架構(gòu)模型的區(qū)別是，第二種架構(gòu)組件的子組件也可以采用分布式部署方式，而該架構(gòu)只能是所有組件all-in-one。這種架構(gòu)由于也

31、是“分布式”，可適用的資源規(guī)模也可以非常大，但顯然沒(méi)有第二種架構(gòu)靈活性高。“動(dòng)態(tài)”理念：部署策略：顧名思議，在資源部署時(shí)能夠按照不同的模板或者策略，自動(dòng)地或者可選擇地部署到不同的資源當(dāng)中。先說(shuō)部署模板，在OpenStack里面叫做Flavor，定義了VCPU，RAM，DISK，Metadata四類，Scheduler會(huì)按照f(shuō)lavor去選擇合適的計(jì)算節(jié)點(diǎn)；在PowerVC里面叫做Templete，有Compute Templete和Storage Templete，按照Templete去計(jì)算節(jié)點(diǎn)中部署資源。再說(shuō)策略，策略在OpenStack中叫做Filter，也就是過(guò)濾規(guī)則，在部署時(shí)，按照規(guī)則

32、的設(shè)定過(guò)濾一遍，最終選擇合適的目標(biāo)計(jì)算節(jié)點(diǎn)進(jìn)行部署。比如RetryFilter（刷掉之前已經(jīng)調(diào)度過(guò)的節(jié)點(diǎn)）、ServerGroupAntiAffinityFilter（可以盡量將 Instance 分散部署到不同的節(jié)點(diǎn)上）、ComputeCapabilitiesFilter（根據(jù)計(jì)算節(jié)點(diǎn)的特性來(lái)篩選）、AvailabilityZoneFilter（為提高容災(zāi)性和提供隔離服務(wù)，可以將計(jì)算節(jié)點(diǎn)劃分到不同的Availability Zone中）等等，并且能夠支持第三方Scheduler，按照Driver的框架，配置Scheduler_driver 即可。最后說(shuō)下策略繼承，云管平臺(tái)的資源層由于是異構(gòu)的

33、資源層，包含了Power、商用X86、開(kāi)源X86、容器、公有云，甚至Z/VM，采用的資源接管方式也不一樣，有的是直接管理，有的是間接管理，直接管理可以采用云管資源層自身設(shè)定的部署策略，而間接管理由于資源池層也存在部署策略（如PowerVC、VC、公有云、容器云）則需要考慮能否將這些部署策略通過(guò)API集成過(guò)來(lái)，或者是不去集成這些策略，直接讀取過(guò)來(lái)，亦或是不去管理這些策略。因?yàn)樵乒苜Y源層的開(kāi)發(fā)者或者廠商和間接管理的這些資源池層廠商不是同一家，相互間的配合和協(xié)同，或者一些API并不開(kāi)放等，所以這一塊，為了簡(jiǎn)便，直接采取不去管理這些策略，一來(lái)必要性也不是那么高，二來(lái)節(jié)約了成本。動(dòng)態(tài)優(yōu)化規(guī)則：動(dòng)態(tài)優(yōu)化規(guī)

34、則是通過(guò)一定的監(jiān)控手段，采集資源使用情況，當(dāng)觸發(fā)優(yōu)化規(guī)則時(shí)，通過(guò)事件通知用戶，或者直接執(zhí)行動(dòng)作去在線遷移資源或者橫縱向擴(kuò)展資源。這里有兩種方式來(lái)實(shí)現(xiàn)，一是通過(guò)Nova組件協(xié)同Ceilometer來(lái)實(shí)現(xiàn)。Ceilometer對(duì)底層資源使用實(shí)時(shí)采集和監(jiān)控，當(dāng)觸發(fā)動(dòng)態(tài)優(yōu)化規(guī)則時(shí)，如計(jì)算節(jié)點(diǎn)CPU使用率、內(nèi)存使用率、使用率連續(xù)3次超過(guò)所設(shè)定的閥值，則開(kāi)始執(zhí)行動(dòng)作，按照虛擬機(jī)的權(quán)重，遷移該計(jì)算節(jié)點(diǎn)上的權(quán)重較低的部分虛擬機(jī)至資源池的其他計(jì)算節(jié)點(diǎn)當(dāng)中。二是通過(guò)Heat組件協(xié)同Ceilometer來(lái)實(shí)現(xiàn)，同樣Ceilometer對(duì)資源使用進(jìn)行采集，當(dāng)觸發(fā)告警閾值時(shí)，通知Heat調(diào)度編排腳本，自動(dòng)橫向部署一個(gè)新

35、的虛擬機(jī)供業(yè)務(wù)使用。Heat對(duì)資源的伸縮編排如下圖所示：2.服務(wù)抽象層的設(shè)計(jì)云管平臺(tái)的服務(wù)抽象層建立在資源層之上，也就是前面所說(shuō)的狹義云管平臺(tái)，官方的定義基本都是這種：Gartner 對(duì) CMP 的定義-CMP (Cloud management platforms，云管理平臺(tái))是一種管理公有云、私有云和混合云環(huán)境的整合性產(chǎn)品，其最小的功能范圍應(yīng)該包括自服務(wù)界面(self-service interfaces)、創(chuàng)建系統(tǒng)鏡像(provision system images)、監(jiān)控和賬單(metering and billing)，以及基于策略的一定程度的負(fù)載優(yōu)化(workload optimi

36、zation)等。高級(jí)的功能還包括整合外部已有的企業(yè)管理系統(tǒng)，包括服務(wù)目錄(service catalogs)、存儲(chǔ)和網(wǎng)絡(luò)資源配置，更高級(jí)的資源管理和監(jiān)控，比如客戶機(jī)性能和可用性監(jiān)控等。具體見(jiàn)下圖：狹義云管平臺(tái)本身來(lái)說(shuō)，并不具備能夠獨(dú)立完成這些能力，而是基于對(duì)底層資源層API和企業(yè)IT管理平臺(tái)API的抽象整合去實(shí)現(xiàn)這些能力，技術(shù)實(shí)現(xiàn)真正是在資源層完成的，下面這張圖則是OpenStack官方核心組件的整體架構(gòu)圖，做了些許微調(diào)。圖中明確地指出了管理OpenStack的三種方法：Command-line interfaces（命令行界面）、GUI Tools（類似于Horizon的Dashboard

37、圖形界面工具)、Cloud Management Tools（Rightscale, Enstratius,etc)。顯然，在大規(guī)模的云計(jì)算運(yùn)維中，使用Command-line interfaces（命令行界面）去執(zhí)行運(yùn)維活動(dòng)是不切實(shí)際的。使用OpenStack Horizon的Dashboard圖形界面工具，其有限的功能對(duì)大規(guī)模的云計(jì)算環(huán)境而言同樣是不完備的。OpenStack的Horizon并不是完整意義上的CMP，作為OpenStack的Dashboard項(xiàng)目，當(dāng)前的Horizon只有很少的一部分CMP功能。Horizon調(diào)用OpenStack的各個(gè)API接口去操作云平臺(tái)資源中的各類資源

38、，提供了管理和操作OpenStack的用戶界面，實(shí)現(xiàn)了 CMP 所要求的一部分功能，但是，它還缺少很多核心功能，盡管基于OpenStack發(fā)展而成的CMP可能是未來(lái)的技術(shù)趨勢(shì)。而OpenStack被專用性強(qiáng)的Cloud Management Tools（CMP）所納管，這是被OpenStack官方所認(rèn)可的管理OpenStack的標(biāo)準(zhǔn)方法之一。另外對(duì)于一些資源層的API（如容器云、公有云），也可直接集成到CMP中，而不僅僅限于放在OpenStack資源層中，其區(qū)別是有些商用CMP產(chǎn)品已經(jīng)實(shí)現(xiàn)了這些集成，不必要再對(duì)OpenStack資源層再定制這些API集成，增加開(kāi)發(fā)量。如果資源層和服務(wù)層（狹義C

39、MP）都是走的研發(fā)路線，可以考慮將資源和服務(wù)徹底分開(kāi)管理。所以我們總結(jié)一下，目前有三種方式來(lái)實(shí)現(xiàn)服務(wù)抽象層：（1）使用OpenStack自帶的Horizon前面也講了，這種方式面向的是基礎(chǔ)資源的管理，缺少很多CMP需要的核心功能，如服務(wù)目錄和編排，多云管理方面也不支持公有云和容器云，計(jì)量計(jì)費(fèi)及成本優(yōu)化等等，面向用戶的美觀感、頁(yè)面布局和體驗(yàn)感差，不友好。（2）定制或者重新開(kāi)發(fā) OpenStack Horizon許多商用軟件廠商重新定制了Horizon，定制分為兩種，一種是基于Horizon社區(qū)提供的 Horizon定制方法所做的非常簡(jiǎn)單的定制，比如更換Logo，簡(jiǎn)單改變布局、更換界面顏色等，很顯

40、然這種定制所帶來(lái)的差異化非常有限；另一種是深度定制甚至重新編寫(xiě)，這能帶來(lái)足夠的差異化，再者也能將一些核心功能補(bǔ)齊，比如通過(guò)集成公有云API，實(shí)現(xiàn)公有云和私有云管理平臺(tái)的整合，還能夠整合用戶的其他管理系統(tǒng)等。（3）運(yùn)用專業(yè)的CMP（商用或者研發(fā)）專業(yè)的CMP考慮的面比較廣，往往以應(yīng)用和用戶為中心，支持各種高級(jí)功能，但目前的一個(gè)事實(shí)是：CMP市場(chǎng)的碎片化程度極高，各產(chǎn)商占有的市場(chǎng)份額都非常低，大部分在10%以下。這個(gè)市場(chǎng)呈現(xiàn)出顯著的戰(zhàn)國(guó)時(shí)代的特征，這預(yù)示著未來(lái)幾年在CMP市場(chǎng)的白熱化的市場(chǎng)競(jìng)爭(zhēng)。對(duì)于我們企業(yè)用戶來(lái)說(shuō)，選擇與自身企業(yè)需求和規(guī)劃相匹配的專業(yè)CMP才是最佳選擇。下面舉四個(gè)專業(yè)商用CMP的

41、例子：RightScale RightCloud：RightCloud能管理公有云和私有云，以及虛擬服務(wù)器和裸金屬服務(wù)器，提供的功能包括自服務(wù)、云管理和云分析等。功能全面、豐富，支持幾乎所有的主流公有云、私有云、虛擬服務(wù)器和裸金屬服務(wù)器等。界面風(fēng)格現(xiàn)代，用戶體驗(yàn)非常好。（1）系統(tǒng)架構(gòu)（2）功能特色云管理: 異構(gòu)環(huán)境統(tǒng)一管理、自動(dòng)化部署與運(yùn)維；統(tǒng)一監(jiān)控與集成、持續(xù)集成與交互。 自服務(wù)-通過(guò)從一個(gè)門戶網(wǎng)站對(duì)多個(gè)云進(jìn)行基于模板的配置，加快開(kāi)發(fā)速度。 云監(jiān)控-支持多云環(huán)境統(tǒng)一監(jiān)控視圖，查看，自動(dòng)化和管理任何云和服務(wù)器上的云資源。 主機(jī)模板-支持多種主機(jī)模板配置，在多云環(huán)境下創(chuàng)建云資源，主機(jī)模板提供一種

42、新的配置方式。 云治理-支持多租戶控制，基于自動(dòng)化策略，對(duì)云環(huán)境下的多租戶進(jìn)行治理和權(quán)限控制，消除障礙，而不會(huì)犧牲控制。云分析：管理和優(yōu)化多云環(huán)境成本；協(xié)同采取行動(dòng)，減少支出。 分析報(bào)告-在統(tǒng)一儀表板中查看來(lái)自公有云和私有云的使用情況及成本數(shù)據(jù)；將成本分?jǐn)偨o對(duì)應(yīng)部門；通過(guò)云帳戶、團(tuán)隊(duì)或應(yīng)用程序維度來(lái)分析成本使用趨勢(shì)。 協(xié)同優(yōu)化-獲得降低成本的自動(dòng)化建議；向right cloud的用戶提供儲(chǔ)蓄建議；通過(guò)儀表盤展現(xiàn)成本降低的趨勢(shì)。 自動(dòng)化的動(dòng)作-為改善未來(lái)的建議提供反饋；一鍵終止或刪除未使用或空閑的資源；優(yōu)化使用AWS保留實(shí)例和Google承諾的折扣。 預(yù)算和預(yù)測(cè)-預(yù)測(cè)未來(lái)或現(xiàn)有云應(yīng)用的未來(lái)成本；

43、制定預(yù)算并提醒用戶或管理者超支；評(píng)估不同的云，實(shí)例類型和購(gòu)買選項(xiàng)。云比較：免費(fèi)的工具，可讓用戶輕松比較領(lǐng)先的公有云提供商所提供的功能。（3）功能列表：Red Hat CloudForms:CloudForms是紅帽公司開(kāi)發(fā)的CMP,功能包括審批流程、合規(guī)、自服務(wù)、記賬和配額管理。能管理多種IT和云環(huán)境功能全面、豐富，能管理多云，支持OpenStack, VMware, KVM, Microsoft和Amazon等云環(huán)境。界面的用戶體驗(yàn)不錯(cuò)，但是其風(fēng)格還是傳統(tǒng)IT管理軟件的風(fēng)格，Redhat 基于CloudForms提供了Open Hybrid Cloud解決方案，該云管理平臺(tái)同時(shí)管理RHEV與

44、OpenStack。（1）系統(tǒng)架構(gòu)（2）功能列表浪潮數(shù)據(jù)中心管理平臺(tái)InCloud Manager:云管理平臺(tái)InCloud Manager是云數(shù)據(jù)中心管理平臺(tái)，面向私有云和混合云市場(chǎng)，提供開(kāi)放、安全的企業(yè)級(jí)云數(shù)據(jù)中心運(yùn)維管理能力。InCloud Manager借由自服務(wù)的管理Portal，提供跨基礎(chǔ)架構(gòu)一致性的功能和體驗(yàn)，幫助企業(yè)加速云的應(yīng)用，實(shí)現(xiàn)業(yè)務(wù)的動(dòng)態(tài)變更，資源的智能管理和服務(wù)的自動(dòng)化交付。（1）系統(tǒng)架構(gòu):（2）功能特色：完善的生態(tài)，異構(gòu)資源的統(tǒng)一管理： 支持主流廠商x86服務(wù)器、K1、IBM小型機(jī)、SmartRack的管理； 支持對(duì)Inspur InCloud Sphere、VMwa

45、re vSphere、Citrix XenServer、IBM PowerVM等多種異構(gòu)虛擬化軟件統(tǒng)一管理: 支持對(duì)容器環(huán)境的接管，可以和容器調(diào)度系統(tǒng)Kubernetes進(jìn)行對(duì)接混合云提供更多業(yè)務(wù)靈活性： 充分利用私有云和公有云的優(yōu)勢(shì)； 客戶根據(jù)業(yè)務(wù)需要，靈活云間切換； 混合云備份容災(zāi)，保障數(shù)據(jù)和業(yè)務(wù)； 打通公有云，開(kāi)啟混合云應(yīng)用的新模式。完善的服務(wù)目錄： 豐富的服務(wù)目錄實(shí)現(xiàn)一體化資源交付； 服務(wù)內(nèi)容涵蓋云主機(jī)、云物理機(jī)、云桌面、云盤、云網(wǎng)絡(luò)、云存儲(chǔ)、云監(jiān)控； 統(tǒng)一的管理平臺(tái)，滿足新建云和增量云的需求。跨地域多數(shù)據(jù)中心管理: 分散的異地?cái)?shù)據(jù)中心協(xié)同管理，高效運(yùn)管； 跨數(shù)據(jù)中心的應(yīng)用和數(shù)據(jù)保護(hù)支

46、撐，保護(hù)業(yè)務(wù)和數(shù)據(jù)； 單一數(shù)據(jù)中心可管理5000+服務(wù)器，2000+虛擬機(jī)，10000+用戶，1000+組織。智能的自動(dòng)化運(yùn)維： 分布式遠(yuǎn)程執(zhí)行系統(tǒng)，可以執(zhí)行任意命令和預(yù)定義的模塊命令； 基于網(wǎng)絡(luò)加載，自動(dòng)化安裝，支持多節(jié)點(diǎn)并發(fā)和一鍵式智能安裝控制； 數(shù)據(jù)庫(kù)、Web應(yīng)用、中間件等服務(wù)的快速交付； 業(yè)務(wù)上線時(shí)間由原來(lái)的幾周、幾天，縮短為幾分鐘。高效的業(yè)務(wù)支撐： 業(yè)務(wù)感知，資源池彈性應(yīng)對(duì)業(yè)務(wù)負(fù)載； 支持軟件負(fù)載均衡和硬件負(fù)載均衡； 根據(jù)自身業(yè)務(wù)情況，靈活添加及修改審批節(jié)點(diǎn)； 實(shí)現(xiàn)訂單歷史全程可追溯，各審批環(huán)節(jié)實(shí)時(shí)提醒。精細(xì)的監(jiān)控管理： 服務(wù)器、存儲(chǔ)、網(wǎng)絡(luò)、操作系統(tǒng)、中間件、數(shù)據(jù)庫(kù)、業(yè)務(wù)應(yīng)用七大監(jiān)控

47、類別； 20000+監(jiān)控項(xiàng)，提供對(duì)數(shù)據(jù)中心全面的監(jiān)控； 巡檢計(jì)劃、巡檢策略和巡檢報(bào)告實(shí)現(xiàn)巡檢任務(wù)策略化； 3D機(jī)房建模實(shí)現(xiàn)物理機(jī)房可視化監(jiān)控； 全生命周期資產(chǎn)管理。安全可靠云平臺(tái)： 符合4A的安全運(yùn)維規(guī)范，提供完備的安全體系； 通過(guò)公安部計(jì)算機(jī)信息系統(tǒng)安全產(chǎn)品質(zhì)量監(jiān)督檢驗(yàn)中心檢測(cè)； 通過(guò)中國(guó)信息安全測(cè)評(píng)中心分級(jí)評(píng)估EAL3+級(jí)安全評(píng)測(cè)和專家驗(yàn)收； 集成第三方安全模塊，支持底層無(wú)代理防護(hù)，實(shí)現(xiàn)操作系統(tǒng)到應(yīng)用層面的多層防御； 全自主研發(fā)，構(gòu)建Web安全、虛擬化安全、數(shù)據(jù)安全、訪問(wèn)控制、安全審計(jì)、多租戶資源安全隔離，可提供端到端的安全管理方案。IBM SelectStack云管平臺(tái)：SelectStack(PMC v2.0)是IBM新一代的易于部署實(shí)施的，集成硬件、管理軟件與實(shí)施服務(wù)為一體的，簡(jiǎn)單快速的實(shí)現(xiàn)動(dòng)態(tài)資源部署的云管理平臺(tái)。（1）系統(tǒng)架構(gòu)（2）功能特色快速可靠地實(shí)現(xiàn)集成化私有云管理平臺(tái) 提供全生命周期的部署服務(wù)，快速提供“即申即用”的云計(jì)算環(huán)境，并且在集成化平臺(tái)中同時(shí)支持多種虛擬化技術(shù)。 提供了虛擬機(jī)、中間件、客戶