云计算环境下的运维管理实践

【编者按】

吕新刚，David Lv, VMware 云计算业务架构师。本篇文章节选自他参与撰写的《中国IT运维能力建设指南》（清华大学出版社）一书中的第七篇第一章。

—Begin—

一、前言

二、当前用户的基本现状和面临的挑战

企业A从2014年开始大规模构建云计算平台，底层虚拟化环境广泛采用的是vSphere技术平台，在构建过程中发现，如何针对构建后的云计算环境进行运维是个急需解决的问题，之前该企业已经构建了较完整的监控运维管理平台，但发现该平台主要是基于传统环境构建的，对当前云化后的环境存在一些空档，如原有监控管理主要针对的是传统的硬件，操作系统，数据库，中间件， 络等组件，但针对虚拟化环境的覆盖是不足的，特别是对于虚拟化技术引入后的云化带来的新的管理需求和挑战考虑不足。

经过几轮调研和讨论初步确定未来的云计算环境下运维管理面临的一些具体挑战如下。

1、配置变化更快，统计分析难，数据不准确

u 云环境虚拟机的产生和释放频度远高于物理环境，平均来看生命周期更短，变化更频繁，因此对其配置状态的跟踪更复杂，整个系统范围内的资产信息更难掌握，传统的统计办法不及时也不准确。

2、容量性能评估难，难以有效分配资源

u 不同于物理机，云环境中多台系统共享资源，不同的业务系统对资源的需求周期不同，传统的系统级CPU，MEM的占用已失去绝对指导意义，并不能完全代表系统资源是否存在瓶颈。

u 同样的道理难以判断服务器资源是否得到了充分利用，是否有必要优化，虚拟机密度是否恰当，企业内部存在较广泛的资源闲置情况。

3、管理缺乏标准和规范

u 虚拟化层在整个系统构建中占的位置越来越重要，但与OS相比系统级的加固和检查机制相对薄弱，成熟度及普及度都不高，存在系统缺陷，安全漏洞，管理不规范等薄弱环节，容易成为新的木桶短板。

4、系统状态更复杂，难以准确评估状态

u 虚拟机环境涉及系统硬件，操作系统， 络以及存储，系统环境更加复杂，传统的设备边界不再那么清晰，承载的VM对资源既共享又竞争，所以系统处于不断的动态调整中，故障域的耦合更加紧密，针对问题根源的判断更加困难。

u 单一类型的监控指标很难判断系统的健康状态，必须收集该物理机上运行的多台虚机机状态进行综合分析。

u 指标专业性强，理解其含义需要专业知识。

其实该用户并不是特例，虚拟化层在现有的基础架构中相对于传统环境是新出现的事物，而恰恰正是这一层的变化带来了当前数据中心基础架构层次巨大的变化，进入了云时代，但当前各企业对云计算的基础虚拟化环境的运维管理还处于空白或非常初级的阶段，这与虚拟化环境在企业IT中所提供的价值和体现的重要性严重不符，IT部门迫切需要成熟的专业管理工具来更有效的管理云环境。而针对传统环境的管理方法和工具在高度动态，系统高度融合（计算、存储、 络）的云环境下存在严重不足。这种不足，会给用户带来如下痛点：

u 虚拟化环境缺乏有效深入的监控措施，管理被动，问题无法及时发现，出现无法有效分析。

u 安全管理上基本无针对虚拟化环境的管理规范，手段及工具，安全短板问题较明显。

u 资产配置信息缺乏深入及时准确的统计分析，基本靠手工，信息与实际环境偏差较大。

u 由于Cloud环境的资源共享和动态配置特性，云环境下的资源管理变得更加复杂难控，资源的惊人浪费和局部资源的紧张情况同时存在存在，如何判断充分利用这些资源，配置合理的虚拟机比例是新环境下的新管理要求。

u 缺乏相关分析 表和面板视图，对于云环境较大规模的环境缺乏全局管理能力。

基于上述分析，我们针对A企业的实际情况提出云环境运维管理的几个关键目标及能力需求如下表所示。

表：云环境运维管理的关键目标及能力需求

三、云环境下管理的关键领域实践

本章节将针对以上分析的几个关键领域容量管理，配置及资产管理，安全及合规管理进行深入探讨。

1、容量管理

容量管理分为容量优化和容量规划，前者关注优化资源配置，提高现有资源利用率。发现并回收低效、未使用的容量，以便合理调整虚拟机大小、回收闲置资源，在不影响性能的情况下优化整合率和虚拟机密度。后者关注容量不足和超额配置情况，以提前规划资源扩容，指导采购，并规避资源风险。

1）容量优化

在企业A，计算资源的需求是由业务或应用开发部门提出的，这种资源的请求一般都会高于实际运行需求，包括资源规格和使用时间两个纬度，都会超出实际需要，这类问题主要是由于业务部门主观上站在自身的角度出于规避风险及方便自身使用，客观上也存在缺少精准估算手段等多重原因导致的，但如果没有一个有效的持续优化机制，长期积累下这类问题就会变的很突出，如下图所示，我们通过专业的评估工具可以看到企业A内部资源的闲置情况相当惊人，而作为资源池的主要管理者由于并不了解业务运行情况往往难以进行有效的主动管理，另外即便针对某类系统进行了容量优化，较高的管理沟通成本也阻碍了这种经验的推广，而且较长的响应周期也难以满足当前云资源池快速响应的特性。针对这类情况企业需要建立专门的资源回收机制，以工具为输入手段，形成相关常态管理制度和流程。

经过认真分析这类资源的闲置一般分成两大类，一类是闲置的虚拟机，用户申请完资源后并没有按计划使用或者使用频度非常低，如下图所示该用户环境中有31%的服务器长期处于资源利用率都非常低的情况。

进一步展开可以看到CPU的闲置时间超过99%。针对这类服务器建议启动主动的回收机制。

还有一类是属于资源利用率不高，如下图所示，通常关键资源的使用少于50%，这类一般是在创建初期配置了较高的资源，但根据长期运行统计数据来看，并不需要如此高的配置，所以可以与业务或应用部门沟通进行适当的减配，如将第一行列出的虚拟机，原有的2vCPU配置减少至一个vCPU的配置，即使采用了所建议的减配配置，资源消耗也不会超出53%。

容量的减配不仅仅体现在节省资源上，还对系统性能有至关重要的影响，根据虚拟机的调度机制，多台虚拟机在竞争主机CPU资源时，必需抢到足够的CPU内核，配置越高需要抢到的内核越多，如果这台服务器上运行的虚拟机都是高出正常配置的话，必然导致资源竞争的加剧，反而可能损失了更多的可运行时间，这也出现了一些奇怪的现象，CPU占用并不高，但明显虚拟机系统运行较慢，但一般这类问题比较隐蔽，不通过深入的分析，使用者较难发现，这个时候用户需要关注查验CPU竞争值参数。

除了虚拟机级的调整外，在主机级别也建议采用动态的虚拟比来合理调配服务器的VM:HOST比例，在用户实际环境中服务器本身的负载和VM的资源消耗是个复杂的动态过程，通常情况下，由于缺乏自动化的评估手段，往往采用某个全局的静态虚拟比经验值，企业A就采用了一个经验值1：8，经过仔细分析发现，有部分环境资源的使用效率并不高，属于比较保守的情况，由于每个系统都有其个性化的运行特征，简单的依据这个值进行配比无法反映系统资源的最佳平衡状态。如下图所示，需要借助一些专业工具对密度比进行动态计算来指导虚拟机的合理分布。

考虑到容量管理是个需要持续改进的过程，项目组决定在现有工作流程中针对容量资源的优化使用形成一套比较长期工作机制，并列入当前的工作管理规范。

2）容量规划

容量规划是用于评估企业增加扩展资源时如何有效的评估需求，当前企业A在这块并没有形成有效的统合的工作机制，主要由各项目组规划申 各自的资源需求，由新的资源需求为主形成新的采购需求，这种策略并没有充分考虑存量资源的情况，对于非项目提前申 未列入采购计划的资源请求，管理员只能从现有资源里分配，所以管理员也会定期根据经验对资源采购计划进行修正，加入依据经验分析对资源采购进行指导，甚至出现资源不足，只能拒绝业务需求或走较长的采购周期以满足需求。经过分析发现这种工作模式存在以下弊端：

1. 资源池并没有通盘考虑，还是以项目条线需求为依据形成新的采购需求，并没有对资源形成有效的整合考虑；

2. 对资源瓶颈的风险预见能力不足，对于资源需求无法及时满足资源需求，可能导致较长的供给周期，或者业务组需要较长的资源规划，而且这种资源规划必不可少会留有充足的资源预留，即提前预支资源，宁可资源闲置也不愿出现资源紧缺再走复杂的操作流程，导致资源采购必然大于实际需求；

3. 对于紧急性临时性需求响应较差，但从业务变革来看越来越多的项目是为快速响应业务出现的，这种类型的需求将成为常态，而且这也正是云计算的优势所在。

这种问题之所以出现，是因为在传统模式下系统部门其实并不是资源规划的主体，而是执行者，但在云时代，资源由原来的各条线规划，转化为集约化管理后，这种模式已不再适用，系统管理员或资源池的管理者应承担资源规划的的主体角色，对整体资源进行统筹规划，要满足统筹规划的需求，就给当前容量的管理提出新的需求，容量的管理者必须能够分析当前资源池和各类资源需求的匹配程度，并能从时间和需求量两个纬度分析资源的需求情况，主动合理规划资源池容量扩充计划，一方面充分利用存量资源，一方面规避容量瓶颈风险。

在本次项目中企业A制定了如下容量规划的工作机制，并确立了由系统管理部门作为资源池容量管理主体，统筹容量规划工作。

如下图所示项目组借助数学模型对收集的数据和使用情况进行趋势分析来评估资源可用时间和余量。

以下为一台具体计算环境的容量使用情况，目前可以看到该台服务器的磁盘空间处于接近耗尽的情况，其它类型资源如CPU，内存还有较多的富余。

增加多少磁盘空间比较合理，可以进一步评估，如下图所示显示了两种类型的方案，一种是增加磁盘资源，一种是移除部分虚拟机，下图显示了两种类型操作对容量评估的影响。

2、配置及资产管理

按照传统工作方式，企业A仍然采用手工统计的方式记录各类资源及资产的情况，通过EXCEL表格生成基本的资产清单，这种方式是在传统硬件管理模式下形成的，以记录资产的硬件属性和对应的业务用途为主，但在云计算环境下，由于资产的高度动态变化特征，导致资产清单更新非常不及时，与实际环境相差比较大，目前主要采用每半年清点的方式进行更新，费时费力，而且很多资产的属性因为资源问题也无法记录，需要的时候重新查验，事后也没有列入常规工作，基本属于一次性工作。主管领导也多次提出整改意见。

经过分析，该问题并不复杂，主要瓶颈在资产的信息采集上，只要采集到相关的各类数据，生成各类分析 表并不困难。而人工采集的成本是阻碍配置资产信息精细化的关键。

因此项目组在本次项目中引入了专业的配置采集工具收集云环境的计算资源信息，并对关键配置数据类型和属性作了如下要求。

如下是依据采集的数据生成的实时资产面板样例。

该类信息同时也可汇总到企业的CMDB中，为企业的总体配置管理提供输入数据。

在日常工作中，项目组建议形成资产定期汇 制度，以定期向管理层更新资产配置及变更情况汇 ，并将其纳入到系统管理部门日常工作内容中。

3、安全及合规管理

企业A对安全非常重视，在企业内部采用了比较严格的安全管理制度，针对各类管理对象都有想关的安全管理规范，在 络层面也有比较严格的安全域划分和管理，但在分析过程中项目组发现这些安全管理元素都延续自传统环境的管理策略。对于云化环境的基础虚拟化部分没有设计针对性的策略规范，下图为采用厂商工具扫描后展示的安全合规情况。明显有较多的安全隐患，实际上不光企业A存在这种情况，大部分企业或单位在云的核心虚拟化环境上的安全管理上都相对滞后，没有针对虚拟化环境采用相关的安全管理工具，并配套相关管理规范。

常见风险项目举例如下：

很明显这些都是用户比较容易忽视的问题，也容易被利用，而且云化环境是个高度动态的环境，一次两次的检查工作并不能有效保持整个环境的持续合规，必须采用较高频度的检查才能减少风险，但用户面临的问题有两个：1.针对该环境检查那些关键项目；2.如何对大的环境进行高频度的检查，前者需要专业领域的知识和经验，后者是人工无法完成的，需要专业的工具支撑。

项目组在参考了厂商和国际标准后制定了针对企业A的安全合规策略。举例如下，以下为针对宿主机的安全检查策略：

为保证整个环境的持续合规，项目组和用户方制定了如下安全管理工作任务，将对环境的安全扫描定义为例行工作，并引入了专业的工具，分别针对不同管理对象进行不同周期的扫描检查，并配合检查结果构建了具体的工作流程，确保整体环境及时有效的封堵安全隐患。

三、小结

回顾整个项目来看，企业A遇到的问题其实在很多企业都存在，这主要是因为针对云计算环境，大部分用户都处于建设阶段，而对运维部分的改进主要集中在工作流程和工作模式上，但对云计算环境自身的新技术特性管控较少，管控深度也不够，一方面是缺乏足够的认识，还没有形成比较体系全面的技术管理经验和知识积累，另一方面是缺乏一些具有专业知识的专业工具的支持。而云计算本身的成功不是建设的成功，是运营的成功，因此后端运维环节是重中之重。企业在构建云计算的过程中不仅仅要关注Day1部署环节的建设，还应加强Day2运维环节的投入。

–End—

同时，欢迎您加入 “开放讨论群-SDS&虚拟化” 微信群，并邀请其他对SDS和虚拟化感兴趣的朋友加入此微信群。可以通过添加如下管理员之一的微信号，建议添加管理员时，告知你的公司名和姓名，方便备注保存。

sdg8848

libo9538

yangzhuan

dts0103

关注后，可以通过点击左下角的“文章目录”，通过输入三位数（记住！是三位数，目前第一位是0或者1）详细了解如何查看历史文章。

—

《中国IT运维能力建设指南》是“国家信息技术服务标准（ITSS）系列丛书”之一，是对国家标准《信息技术服务 运行维护 第1部分 通用要求》（GB/T28827.1）的解读与应用。 感兴趣的朋友可以直接打开左下角 “阅读原文“，前去清华大学出版社购买。