在2017届OpenStack summit中，我们除了了解OpenStack的一些动向、技术等，还有另外一个感受，那就是ansible的重要性越来越高。使用关键字ansible搜索，标题中带ansible的话题就有11个，其它与ansible相关的话题也有很多。1.Deploying OpenStack at scale with TripleO, Ansible, and Containers2.OpenStack-Ansible users and ops feedback session3.Migrating your job from jenkins Job Builder to Ansible Playbooks, a Zuulv3 story4.Ansible - Project Onboarding5.Ansible: State of the Union, our friendship with OpenStack, and more6.Windmill 101: Ansible based deployment for Zuul / Nodepool7.Deploying Multi-Container Applications with Ansible Service Broker8.Heat orchestration using Ansible9.OpenStack-Ansible - Project Update10.Using Ansible to Automate the Entire IT Stack11.Practical Kubernetes with Magnum and OpenStack-Ansible其实在ansible之前，市面上已经有很多常见的自动化运维工具，如chef，puppet，saltstack。ansible之所以火爆，笔者分析有两点很重要：1. ansible是基于python的python*近几年非常受欢迎，目前从事运维和部署的人，或多或少都有一些使用python的能力。而chef和puppet都基于ruby，saltstack也基于python。所以很多人在选择自动化运维工具的时候，会倾向于ansible和saltstack。2. ansible是无代理的无代理，即不需要在被管理的节点安装任何客户端或者其它软件，它只需要被管理节点支持ssh和python，而这两项基本上在管理节点上是默认支持的。这无疑是一个很强的特点，不仅使人们容易上手，更减少了维护客户端的成本。从另一个方面讲，当ansible有新的版本发布时，运维人员只需要在ansible控制节点更新软件，并做出相应调整即可。而saltstack的亮点则是使用了消息队列(zero mq)和客户端，所以在ansible和saltstack之间，大家会倾向于ansible。ansible其他特点除了上面的讲的以外，ansible还有其它一些特点，这些同样也是很吸引人的:1.简单ansible的ad-hoc命令和playbook都是用户和机器可读的，所以学习成本很低，不需要特殊的代码技能，很容易上手所以学习成本很低，不需要特殊的代码技能，很容易上手。2.强大它能帮助我们做什么？几乎我们能想到的日常操作，它都可以实现。不仅原生提供1000+的模块，还可以从ansible galaxy分享自己的和别人的模块3.可扩展ansible支持用户自定义模块，而且不限定这些模块所使用的语言。ansible执行模块时，主要是将相应的脚本传到被管理节点，然后执行它，只要脚本能以json格式返回结果即可。4.可编排ansible playbook可以将host与role进行编排，所以可以在不同的host节点执行不同的任务。在ansible中，task是按序执行的，当管理多个节点时，只有当一个task在所有节点执行完成，下一个task才会被执行。如何提高ansible的运行速度可能会有一些反对的声音，因为ansible使用ssh与被控节点通讯，所以运行起来会比较慢。实际情况可能是这样的，但我们可以做一些事情来提高ansible的运行速度，比如1. 开启SSH pipelining一般情况下，ansible在执行task时，会有3次ssh连接，包括：1.1 在被管理节点创建临时目录1.2 将脚本发送到临时目录1.3 执行脚本并返回结果开启SSH pipelining后，ansible在执行task时，不需要建立临时目录和发送脚本，只需要一次ssh连接，在这次连接中把脚本作为stdin写入。2. 开启ControlPersist这可能需要升级ssh到比较新的版本。开启ControlPersist之后，当断开ssh会话时，连接并没有被销毁，所以下次建立会话时，可以直接使用该连接，这可以节省很多时间。总结综合上面的分析，相信大家能够体会到ansible的强大之处。它不仅能帮助解决日常的IT运维问题，就连部署OpenStack和kubernetes都能轻松应对。正如今天峰会上的一个议题一样，"Using Ansible to Automate the Entire IT Stack"。

联盟成员案例分享——鼎震科技  1    项目背景  随着广电行业全媒体融合发展的大趋势，BTV（北京电视台）迫切需要在目前技术体系的基础上，结合三网融合和全媒体发展新局面，进行基于全媒体云架构应用系统的建设，以满足传统技术体系向全媒体支持转型的需要。智慧媒体制播云平台作为BTV新一代的节目制播生产平台，将成为BTV未来的全媒体制播生产服务的支撑性平台。 2   客户需求 智慧媒体制播云平台是一个承上启下的关键平台，向下要统一管理和调度所有虚拟化以后的计算、网络、存储资源，向上要对上层业务系统提供 IaaS 服务，同时还要与现有的一些周边系统进行对接。除了提供基础的 IaaS 云服务以外，建设这个平台还必须解决以下难题：1、与多家底层虚拟化基础设施方案厂商同时对接。为了规避单一供应商带来的风险，BTV决定该平台的底层虚拟化基础设施由华为和华三两家同时提供，而华为与华三的云管理平台却不能对接，存在无法彼此管理的问题，运维人员将面对两套管理系统、两套管理流程和两套管理数据。2、避免厂商锁定。虽然采用了两家底层虚拟化基础设施供应商，但是BTV不希望基于任何一家的私有接口进行上层业务系统的开发，以避免上层业务系统被锁定。3、采用开放的架构，把握未来的趋势。BTV希望云管理平台基于标准的 OpenStack架构，紧跟云计算技术发展的趋势并保持充分的开放，以满足未来的业务发展需求。4、对接上层业务系统、周边服务系统。上层业务系统对即将部署的 IaaS 云平台提出了一些特殊的需求（如 GPU 挂载、虚拟化资源弹性伸缩等），与现有周边服务系统的对接（如接入现有统一认证系统、直接对接 NFS 存储系统等）也要求这个云平台具备灵活的定制交付能力。 3  解决方案BTV基于鼎震科技的 DigZeta iCloudBase（IaaS 云统一管理平台）和 DigZeta SmartAdapting（云定制咨询服务）顺利完成了智慧媒体制播云平台的建设。DigZeta iCloudBase 是鼎震科技开发的基于标准 OpenStack 的 IaaS 云统一管理平台。这个平台通过标准的 OpenStack 向下统一管理各种异构的虚拟化基础设施（无论是商业方案还是开源方案），为上层操作提供统一的界面、流程和管理数据；这个平台同时向上层业务系统提供标准的 OpenStack操作接口，使用这些接口开发的上层应用系统能够“零开发”地运行到其他任何基于标准OpenStack接口的云管理平台上去。与标准 OpenStack 全向兼容的 DigZeta iCloudBase 构成了智慧媒体制播云平台的核心层，因为采用了 OpenStack 接口与架构作为贯穿上下的标准，所以在未来五到十年内，BTV都将处于云计算技术与发展趋势的最前沿，在国内牢牢占据领导地位。DigZeta SmartAdapting 是鼎震科技为行业用户提供的云定制咨询服务，专门解决私有云在行业落地时的非标对接问题。基于这一服务，鼎震科技为BTV定制开发了上层业务系统与云平台的对接、与第三方 NFS 存储系统的直接对接、与已有认证系统对接等模块，这些模块是智慧媒体制播云平台能够正常运转不可或缺的组成部分。   4    客户收益  全面利用 IaaS 云资源快速交付和业务快速开通的能力，并且在**程度上提高资源利用率；用统一的管理平台、操作界面、处理流程管理异构的底层虚拟化基础设施，同时避免单一厂商的锁定；紧紧把握云计算的发展趋势，充分利用 OpenStack 的优点，成功规避OpenStack 可管理性低、可操作性差等缺点；与上层业务系统、周边服务系统**对接，让私有云在现有业务和 IT 系统中真正落地。      （长按图片识别二维码关注）

一旦您已经完成了 OpenStack 的概念性论证，您需要权衡各项指标，从而决定****率和验证创建生产环境下的 OpenStack 商业案例。验证任何 IT 项目的****率都是一个挑战。但是 Mirantis 可以准确的帮您判断 OpenStack 部署的价值。图例：Mirantis StackLight 仪表盘可以帮助计算部署 OpenStack 所带来的ROI衡量 OpenStack 概念性验证的****率的第一步是决定你们部门想要取得的商业价值是什么。您的****率的计算需要依据于部署 OpenStack 私有云带来的真实的商业利益。例如，OpenStack 概念验证是否真的带来了商业利益？ 通过增加应用程序的可靠性，自动化操作和更高的开发速度带来的成本降低。 更短的应用上线时间或者更长的应用在线时间带来的收入上的提高。 主要的 OpenStack ****度量以上三图展示了一些潜在的关键 OpenStack ****率度量方法理解这些问题的答案和处理关于成本、速度、敏捷和操作效率相关的数据，是衡量****率非常好的起点。Mirantis StackLight 可以帮助提供衡量ROI的可操作数据。使用了 StackLight 之后，公司可以定制仪表盘来显示 OpenStack 部署带来的价值，捕捉具体的数字，例如使用趋势、IT 成本节约、收入增加和***生产力价值。在衡量了您的 OpenStack 部署的****率之后，您将能够更好的得出 OpenStack 私有云给您的部门所带来的巨大价值。OverStock 由 OpenStack 带来生产力的提升OverStock, 全球零售商，发现 OpenStack 给公司在灵活管理400多个 Java 应用程序中所带来的巨大价值。在部署 OpenStack 私有云之前，OverStock 的350个***需要3个月的时间部署一整套的开发环境。OpenStack 将这个时间缩短到了15分钟。OpenStack 同时还提高了 IT 部门的生产效率。它使得  OverStock 的系统管理员在重复的发布工作中花费更少的时间，使得他们有更多的时间来寻找好的解决方案。看看 OpenStack 如何帮助您的企业一个运行在 Intel Xeon 处理器家族上的私有云，可以在快速开发、时时在线商业环境中获得以下好处：增加 IT 由自动化软件开发周期，允许***更快速地发布软件，增加了 IT 的敏捷性。通过自动化 IT 部署，缩短了***的等待时间，大大提升了 IT 的生产率。通过开放的标准，减少了成本，从而提升了 IT 资源利用率。OpenStack，＊＊的开源云解决方案，它给部门提供了云解决方案从而加速了产品的开发，缩短了上线时间。备注：本文出自 Intel 和 Mirantis 联合著作的私有云研究报告。      （长按图片识别二维码关注）

一个成功的私有云部署案例需要正确的决策者尽可能早的定义成功关键点和矫正最终价值。此外，云平台的构建者和初始租户需要得到管理层的支持，例如 CIO 或者 CTO 的支持。管理层的帮助可以使得云平台技术在不同部门之间推广，从而帮助确定重要的下一步策略：衡量标准和里程碑。任何私有云的评估都必须考虑该项目的商业价值。作为整个计划的一部分，部门管理者必须为考量该项目是否成功制定关键的考量点和里程碑。一旦考量点、云平台构建者、初始租户和管理层的支持都有了，下一步就是勾勒出清晰地取得项目成功的实施和投资的三个阶段。下面的图表给出了这三个阶段和每个阶段分别的需求。取得私有云平台转变的三个阶段创建一个成功的 OpenStack 计划一旦管理者理解了制定一个云平台策略不仅仅是预算单里简单几行文字，他们就可以开始为 OpenStack 进行概念验证方案了。Mirantis 提供了一整套基于 Intel Xeon 处理器家族具体的构架解决方案。这个方案可以作为任何规模和复杂度的概念验证方案的起点。一旦基础构架和执行组已经熟悉了基本的 OpenStack 云构架方案，他们可以进行规划具有高可用功能的概念验证方案，从而为私有云核心接口提供99.99%的在线时间。这些功能可以为初始租户部署健壮的、可恢复的商业应用做基础。管理 OpenStack 基础平台的＊＊实践方案一旦管理部门确定了 OpenStack 概念验证基础构架方案，执行部门应该遵循＊＊实践方案，从而达到99.99%的在线时间和可靠性。深入讨论＊＊实践方案已经超出了本文的范围，以下几点是执行部门应该关注的基本方面：安全性：OpenStack 安全性的部署实施，是概念验证的关键点。它包括了理解一般性的威胁、模块受到的威胁以及如何消除威胁。日志：在概念验证环境中可能会涉及到设置适当的日志，这对决绝具体问题至关重要。OpenStack 通过Linux标准的 syslog 和 rsyslog 来管理日志。Fuel 同时提供了在网页界面上浏览日志的能力。监控和报警：除了日志之外，监控系统提供了检测 OpenStack 和主机健康度的能力。监控系统帮助管理员和工程师实时的对系统和操作问题作出响应。一个健壮的检测系统可以通过提供自动发现和配置管理来减少手工配置带来的错误。问题解决：一个 OpenStack 部署环境是由众多技术协同工作，从而提供的私有云服务。解决由监控和报警系统汇报的问题有时候并不容易。幸运的是，OpenStack 基金会对于实际使用、实施当中遇到的问题，提供了一些易于理解的技术文章。操作指南：操作指南提供了在不同环境中的部署技术。Mirantis 提供了 Mirantis OpenStack 认证系统。它除了为这些方案提供部署的轮廓信息和操作指导，还可以向合作者证明解决方案是基于 Mirantis OpenStack 基础之上的。在遵循了＊＊操作实践步骤之后，云平台操作人员可以保证其可靠性、实时在线性，最终取得**的****率(ROI)，明天即将发布的第五章，我们会详解 ROI，敬请期待。人力资源公司提高了***的生产力一个人力资源公司需要超过20天才可以完成部署一整套开发环境，它包括了开发虚拟机、数据库、应用服务程序、网页服务、网络配置和安全证书。在有了 OpenStack 之后，公司可以把部署时间从20多天缩短到一个工作日。它可以帮助***提高至少10%的生产力，一个财年可以预计节约 370万美元。备注：本文出自 Intel 和 Mirantis 联合著作的私有云研究报告。      （长按图片识别二维码关注）

在以AWS、Google、阿里等为代表的公有云发展的同时，很多大型企业出于数据安全性、系统稳定性、软硬件自主权、对自主可控以及在完整生命周期内TCO（总体拥有成本）低的考虑，更加倾向于建设企业私有云来承载内部业务信息系统的运行。构建企业私有云并非是一蹴而就的，正如Gartner的副总裁Tom Bittman所述“部署私有云并不是简单地对硬件进行采购，而是一场革新”.对于企业私有云而言，其建设同样应遵循信息系统建设的通用方法，即事先分析规划、事中落地实现以及事后运维管理.本文从企业私有云建设需求分析，企业私有云建设要点以及企业私有云的运维与管理等三个方面对大型企业私有云建设思路进行分析。一、企业私有云建设需求分析在建设企业私有云前，首先需要回答和解决的问题是企业是否真的需要私有云，需要什么样的私有云？企业私有云的建设是一个长期的系统工程，初始成本的投入也较为高昂.因此企业在建设私有云之前，应从以下几方面对需求和现状进行评估。1、需求和资源使用特点某大型企业的IT系统现状：系统利用率低：烟囱式的系统建设部署方式，导致系统资源无法共享，系统负载不均衡，整体资源利用率和能耗效率低。建设扩容成本高：IT系统中原有的UNIX服务器、数据库和盘阵占比较高，标准化程度低，通用性差，导致建设扩容成本难以控制，给系统统一维护带来困难。扩展能力有限：系统的Scale-Up能力和Scale-out能力不足，难以应对越来越大的系统处理和存储压力。那么针对以上的现状，如何去通过云计算来改变呢？首先我们需要的是：动态部署架构：构建基于标准化硬件设备和虚拟化架构之上的云计算基础设施资源池可对上层应用按需提供弹性资源，实现多系统有效共享，有效提高IT系统资源利用率和能耗效率。标准硬件单元：云计算采用标准的运算和存储处理单元，有效降低系统建设和扩容成本。高可扩展性：云计算硬件集群技术和软件并行处理能力能够提供出色的Scale-out能力，几乎无限扩展IT系统的处理和存储能力。 通过引入云计算技术，去改变传统信息系统竖井式的建设模式，通过底层资源的共享与灵活调度提升资源利用率，降低整体信息系统建设成本，缩短信息系统的建设周期.这些实现都是以资源使用特点为前提的，如果一个信息系统本身无资源调度需求（例如资源使用曲线较为平稳）；或计划由云计算承载的信息系统整体资源规模较小，资源共享和调度的空间有限；再或特定的应用系统不支持分布式部署，无法进行横向扩展甚至纵向扩展.对于类似的信息系统建设需求，则无法充分利用云计算的优势.因此对本企业的需求和现状进行合理评估是非常必要的。 2、信息系统的标准化程度在云计算环境中，信息系统所具有的标准化程度往往是决定私有云形态的重要因素.对信息系统的标准化评估存在多个维度，包括基础架构环境标准化（例如所需支撑的硬件是专用硬件还是通用硬件）、平台环境标准化（例如对于开发环境、中间件环境以及数据库环境的通用需求和租户限制）、以及应用系统的标准化（例如应用系统的运行环境、封闭系统亦或是开发系统、商用套装软件或是自开发系统、是否支持分布式等）.不同维度的标准化实现决定了企业私有云应该建设为IaaS云、PaaS云亦或是SaaS云。3、云化建设/迁移的难度将新的应用系统直接部署在云计算环境中或将原有系统迁移到云计算环境中是两种主要信息系统的云化改造路径，对其实现难度的评估是对应用系统进行云化改造风险与收益评估的重要手段.整个业务系统的云化分析过程需要从包括硬件支撑环境改造、操作系统平台变更、平台软件绑定分析、IP地址依赖性消除、API重构、模块化改造、标准化改造、外部依赖条件等在内的多个层面和维度进行，准确评估业务信息系统云化改造的相关难点与痛点，才能对信息系统云化改造有充分的认识和准备。4、关于成本的评估与考虑大型企业建设私有云往往会考虑定制化和一些业务特定的需求，其标准化程度往往低于公有云，由此所带来的自动化、运维、管理开销会更高；**，培养大量开发人才在传统企业环境要求则更高，工作技能、职能的转变同样需要成本的投入。二、企业私有云技术路线选择在大型企业建设私有云时，一个重要的问题就是技术路线的选择和成本价值产出. 一般在进行私有云技术路线选择时，大型企业往往会把稳定性、成熟度、服务满意达成度放在首位，那么成熟的稳定的商业解决方案就会被优先考虑，而开源的往往技术不够成熟和稳定，因此不被优先考虑。下面拿VMWARE和OPENSTACK来做比较。从产品设计上看。VMware软件套件是自底向上的架构，下端边界为虚拟机管理器。VMware的vSphere和vClouddirector产品都是依赖于ESX(i) 虚拟机管理器。VMware的产品由于其架构的健壮性，很多高规格用户在多数据中心规模的环境中都有使用。但是VMware的软件系统是封闭的，并且软件的发展路线是完全遵循VMware自己的发展目标，用户或消费者在此方面没有任何控制权。而OpenStack作为一个开源系统，没有任何一家单独的公司在控制OpenStack的发展路线。另外很多大公司都在支持OpenStack发展，有了如此多公司的资源投入，OpenStack的发展是多元化的。然而这也带来了问题，就是OpenStack部署和架构的实施和维护成本较比VMware有了陡然提高，与此同时，由于相对快速的版本更新速度，技术支持文档不能跟上产品的脚步。从高可用和容错、资源平衡功能上看。在vSphere中，虚拟机级别的高可用性是允许在虚拟机或者ESX(i)主机出错时，在不同宿主机部署相同的虚拟机。高可用是在硬件出问题的时候保证虚拟机的正常工作，当然如果真的出错了，那么只能在不同的ESX(i)主机上启动虚拟机，这也可能造成服务的中断。FT的容错其主要功能就是保证出现故障时用户的应用不会出现中断。其原理就是在两台主机上创建一模一样两台虚拟机vm（主）与vm（辅助），vm（辅助）完全同步vm（主）的操作，当vm（主）故障时，vm（辅助）自动切换变为vm（主）。FT可使应用程序实现零停机、零数据丢失，同时消除了传统硬件或软件集群解决方案的成本和复杂性。另外还有VMware vSphere 的分布式资源调度（DRS）可以聚合群集中ESXi主机资源，通过监控利用率，自动分配这些资源给虚拟机，并能够跨ESXi主机不断进行虚拟机资源优化和平衡。我们再看一下OpenStack 的高可用。目前并没有官方声明OpenStack支持虚拟机级别的高可用性，这个特性在Folsom版本被提出，但是后续又被放弃了。目前OpenStack有一个孵化项目Evacuate, 其作用是为OpenStack提供虚拟机级别高可用支持。再看OpenStack 的容错，在OpenStack中没有针对于容错的功能，并且截至目前也没有计划去完成这些功能。OPENSTACK也还没有良好的资源自动平衡机制，截止到目前openstack并未提供DRS、的功能，这属于openstack功能缺失的一部分。我们可以看到，在功能的支持方面和功能细节，OpenStack与VMware还是有差距的，仍然需要不断进步才能做的更好。 从成本和价值来看。VMWARE是商业软件，其成熟度和稳定性经受了大量实际环境的考验，但使用成本高，体现在其授权费用和服务费用上。相对VMware的昂贵价格，OpenStack免费、开放的优势还是很明显的。VMware高投入带来的功能，OpenStack大部分可以免费提供给客户。那么是OpenStack还是VMware更有价值，这个问题并没有很清晰的答案，并且答案也取决于企业实际部署的规模。虽然OpenStack是免费使用的，但是它需要有专业的开发人员和此领域的专家才行，并且需要很多架构和搭建方面的工作，因为它支持很多部署场景，并且安装过程都不尽相同。VMware则需要花费一些经费购买授权和服务，并且相对来说更加容易安装和运行，另外Vmware的学习成本更低一些。 总得来说，基于以上的分析，大型企业使用VMWARE则更稳定和可靠。而OpenStack则入门门槛较高，如果企业没有足够的技术能力储备则无法解决大面积部署OPENSTACK所遇到的问题和坑。　三、企业私有云建设要点分析构建私有云始于企业对自身信息系统建设需求的解析与明确，企业之所以选择私有云的初衷大多基于自身信息化建设的考虑，主要驱动力包括降低软硬件成本、实现应用系统快速部署、应对业务负载突发性增长需求、构建安全可靠自主可控的基础架构环境等.而私有云对以上需求的支持并非是天然的，在架构设计需要明确设计要点和建设思路，一般说来，在设计企业私有云过程中需要对以下重点关注.1、资源池云计算要进行软硬件资源的统一管控和灵活调度，首先需要做到的就是对资源的纳管，即构建资源池.而需要注意的是资源池的意义并非仅仅是通过平台使软硬件资源的可知可控成为可能，更为重要的是明确与之相匹配的管控手段和策略，使其涵盖资源的全生命周期管理.资源池建设重点可以归纳为资源可达、规模可控与能力可知：1)资源可达资源池是在技术层面打破旧有的竖井式信息系统建设模式的关键，是软硬件资源实现统一管控、灵活调度的基础.在资源池中，需要利用服务器虚拟化、存储虚拟化和网络虚拟化技术，使任意资源在技术上都可以通过网络（IP网络或存储网络）以服务的形式被无障碍、无区别的供给，应用可以以多种方式访问和使用既定规则允许范围内的任意资源.因此，在资源池设计中，对各类型资源的打通和连接是其实现重点.2)规模可控我们在谈及云计算时，往往会说云计算提供了几乎无限的可能性，这主要是在指云计算的弹性.云计算由于在架构设计上避免了底层硬件资源孤岛，对资源的共享访问方式将放大资源池的弹性效果.规模可控的实现最为重要的是制定资源池扩展和收缩的规则，通过使用时间、使用量、持续时间、优先级等一系列量化阈值触发规则在资源池体量不足时可以灵活的向资源池中添加各种资源，在资源池空闲时，也可以释放部分资源给其他资源池使用.3)能力可知在资源池投入使用后，应实时/准实时的对资源池的承载能力进行分析.以监控数据为基础，通过具备科学完备的统计方法和计算规则，评估可供给的服务能力，对应用需求的满足度进行分析.要实现资源池的能力可知，必须具备完善的资源监控手段、实时/准实时更新CMDB，采用合理的感知方式并制定合理的资源能力计算规则，同时，由于应用需求各不相同，要准确评估对应用的满足度，还需要梳理出典型业务模型，据此评估不同应用模型对资源的需求与消耗.2、 云管理平台云服务设计、发布和管理是云计算的核心，体现了云计算的运营形态，而云管理平台是实现云服务全生命周期管理的基础，是实现云计算运营模式的载体.按照ISO/IEC**发布的云计算参考架构，其中功能层中的用户功能层、访问功能层和服务功能层都应该在云管理平台中进行实现.对于云管理平台而言，其建设重点可以归纳为状态可视、分配可控和服务可用：1)状态可视对于云平台而言，可视并不仅仅代表图形化的访问和管控，企业建设私有云更为重要的是从云服务供应商的视角通过云管理平台实现对资源的集中管控。因此在云计算环境中，监控的重要性将上升到****的高度，同时相比于传统信息系统架构，监控的含义和涵盖的范围也有了很大的变化，一般说来，在企业私有云平台中，必须具备对包括基础架构资源、服务、安全审计在内的监控能力：①对包括物理和虚拟化计算资源、存储资源、网络资源等基础架构资源的资产管理、使用情况和设备状态的监控，并及时发现、处理和上报问题.②面向服务的监控主要集中在两个方面.一方面监控上线服务的运行状态，确保其运转正常，及时发现事件与问题；另一方面是对SLA服务等级的达成度监控.③安全和审计的监控包括根据在云计算环境中依照业务需求制定的安全规范，面向用户访问、租户数据/资源隔离、日志采集和分析等进行安全和合规性检查和监控.做到风险可识别、问题可发现、访问可控制、操作可追溯，达成SLA对安全的要求与约定.2)分配可控基础架构资源的管控是云计算运营最重要的基础和最核心的资源.对基础架构资源的合理管控是企业建设自己的私有云的重要出发点，而对资源管控的实现需要通过云管理平台完成.对于云计算环境中的基础架构资源，从初始建设、分配使用在到回收等一系列动作都应该根据服务设计和相关SLA规定制定详细、规范的流程以及科学合理的处理手段，使云管理平台对资源的管控涵盖资源的全生命周期，做到初始建设合理、管控过程合规、资源分配合适、管控操作可回溯、已分配资源可回收.3)服务可用服务是云计算环境的核心.在构建私有云时企业往往会从自身的应用特点和需求出发进行服务的设计和实现，因此很难针对私有云制定通用的服务模板，依据云计算建设的通用方法，对于云服务的建设，一般说来会关注以下四个方面：① 云服务的识别：云服务的识别是云服务实现的第一步，决定了在云计算环境中将供给的服务内容.云服务的识别是以需求调研为基础的，从必要性、可复用性、实现成本等多个角度出发，分析服务实现的难点和收益，制定服务分阶段实现的计划与路线图.②云服务的设计：在云计算环境中对云服务的使用模式决定了云服务的设计要点，一般说来，对于云服务的设计内容包括服务的底层架构、服务的运行流程、服务安全与监控、服务的审计与合规性检查、评价服务能力的关键指标（KPI）、服务的高可用、服务的SLA等几个方面.③云服务的实现：云服务的实现一般说来有四种方式：一是从业务需求分析出发进行云服务的定制开发；二是利用第三方软硬件产品进行服务封装；三是从其他云计算运营商购买，合作实现；四是基于已有服务进行服务组合，形成新的服务.④云服务的维护：在云服务上线后，对云服务的运维是企业私有云成败的关键.对于云服务的维护包括两个方面.一是针对云服务自身的维护，包括对服务能力和状态的监控、对服务性能和规模的趋势分析、服务的修正与升级、服务底层架构的维护等；二是服务的SLA达成度保障，包括实时监控服务的KPI并与SLA所规定的服务目标进行比较，在不符合SLA时及时干预使其符合要求，同时，确保满足SLA所规定的安全、隔离等相关条款.3、自动化与标准化在云计算环境中，自动化对象往往是哪些经常使用、手工发起的复杂操作，这就要求自动化的对象应符合通用设计，遵循相同的技术规范，具备一致的处理流程，动作行为可参数化，即自动化的目标应该是标准化的.标准化实现的层次决定了可以实现自动化操作的对象，而这往往决定了云计算的建设模式.例如，在基础架构资源在资源分配方式、资源分配粒度、资源分配方法等符合标准化时，可以考虑构建基于基础架构资源的IaaS云，在包括开发环境、数据库、中间件在内的平台软件在符合标准架构和流程、具备标准化运行环境等条件时，可以考虑构建基于平台的PaaS云，而在应用部署模式相类、服务模式统一、支持分布式、基于SOA架构等的应用系统等，可以考虑构建基于软件SaaS云.需要注意的是并非所有的基础架构、平台软件和应用软件都具备标准化的条件，而标准化的代价同样高昂，包括硬件重构、SOA改造等标准化过程需要投入大量的资金和人力成本，一般说来，封闭的系统环境和商用套装软件的标准化改造难度较大.另外一点在自动化过程中特别需要考虑的是，自动化在带来便捷、高效的同时，不合理的自动化流程设计将可能会导致错误的蔓延和环境的失控.因此，在进行自动化设计过程中，尤其需要注意规则的设定和异常处理.4、云安全企业不使用公有云而选择自建私有云**的考虑就在于安全.数据表明，安全已经成为阻碍云计算发展的最主要原因之一.根据CDA数据分析师协会统计，32%已经使用云计算的组织和45%尚未使用云计算的组织将云安全作为进一步部署云的**障碍.在云计算体系中，安全涉及到很多层面，一般说来，在云计算环境中应主要考虑网络安全、存储安全、物理机安全、虚拟化安全、虚拟化管理安全、交付层安全、数据安全、安全服务和运维安全等9个层面和领域.同样需要注意的是，并非所有的应用安全问题都应该依赖云计算环境的安全架构来解决.云计算基础架构环境支持的系统种类众多、业务要求和安全基线各有不同，在对用户进行服务供给时应根据服务种类以及SLA对安全服务内容进行严格的规范，划分清晰的分工和责任界面.四、企业私有云建设的思考企业私有云的建设并非只是新技术的变革与引入，而是颠覆传统信息系统建设模式的系统工程.结合企业的特定需求，企业私有云的建设思路大可不尽相同，建设方法也不会千篇一律。是选择商用云平台还是选择开源云平台来创建企业的私有云，这需要企业综合考虑，权衡利弊，依据企业自身技术能力，资金投入总量，实现业务效果等等各个方面去考虑云平台技术选型。所以没有好与不好，只是能否适用和用的好。建设企业私有云不是一蹴而就的，而且这将是持续不断的投入过程，需要在实践中不断摸索前进。KVM社区QQ群，99.99%纯技术交流气氛 QQ 2群：131961942，加入密码大写KVM 千人VMWare技术交流群：494084329，加入密码小写vm OpenNebula QQ群：495571573 加入密码NebulaOpenStack开发纯技术群： 334605713 加入密码novaCloudstack纯技术交流群：515249455密码cs桌面云行业讨论： 484979056 加入密码大写VDI