云计算环境下数据中心管理运行探讨

　　管理是IT系统良性运行的重要保障，不同的IT设备都有自己的管理系统。特别是大规模数据中心，必须通过集中的管理系统来运行管理计算、存储、网络等设备，以能够快速响应和处理数据中心的业务变更、异常事件、持续优化。在《IP领航》往期的文章中曾多次聚焦"数据中心的管理"，但大都侧重于"以网络为核心"的管理，本文将把视线放大到整个云计算环境下的数据中心，对三种运行管理模型逐一对比分析。

　　一、云计算对运行管理变革的驱动

　　传统数据中心，基础架构层面设备之间通过标准化连接和协议互通，保证了计算、存储、网络设备的管理系统之间相互分离、独立(如图1所示)，从而使得不同的运维团队可以按照自身业务发展与架构演进的趋势不断完善和深化各自的管理规程，满足数据中心业务不断发展的要求。

　　图1传统数据中心管理运行架构

　　在云计算环境下，各自独立分离的运行模式不能支持云服务的展开，新的IT运行模式对传统的管理架构提出了挑战：

　　虚拟化:传统数据中心中每个物理服务器上只是单个或几个应用的固定运行，业务基本是与主机的绑定运行方式，对主机的管理，某种意义上也就是对业务的管理。云计算环境下服务器大量采用虚拟化技术，每一个物理网络端口下都会分布多达数十个虚拟机，物理主机上运行着多个不同的操作系统和应用，网络中应用密集度极大增长，对网络的性能、规格、可靠性都提出更高要求，而虚拟机网络属性的可管理性更是面临巨大挑战。

　　动态性:传统数据中心的业务针对物理主机展开，而物理服务器一般固定连接在某个网络端口上，并且业务属性单一，无论是网络策略、安全控制都比较固定。只要主机与网络运维界面清晰、系统归属明确，则业务容易展开，并能平稳运行。但是云计算环境下部署着高密度的虚拟机，在虚拟化环境下，基于服务变更、容灾、分布式计算等业务运行要求使得虚拟机动态迁移成为必备属性。如果网络无法感知这种动态性计算方式，持续的运行必将造成业务的紊乱、运维的不可控，这就要求管理系统能够具备动态计算的感知能力。

　　关联性:当前的网络与计算之间以一种松耦合方式运行，网管与主机管理系统之间基本上没有信息关联交互，这样，对于虚拟化数据中心，虚拟机的动态性计算特性，网络无法感知、网络管理系统无法对虚拟机进行定位，网络对业务的安全、控制、配置、监管便无法关联到虚拟机，无法实现云计算下的灵活部署和扩展性。

　　自动化:在非虚拟化环境中，业务部署后一般都具有相对的固定性，即主机位置、网络接入比较确定，运行维护的目标与物理机、物理端口一致，这种情况，主机系统、网管系统分别部署、调试对接相对比较容易。但在大规模数据中心，特别是云计算环境下的业务流程，基于传统的分离调试是无法有效支持云服务的业务模式，这就要求整个服务的供应应能够简单提交、且不同系统(基础的计算、网络，上层的主机、网络管理系统)之间能够交互服务信息，并基于一致的业务要求完成所有部件的自动化部署与运行。

　　二、云计算管理的目标

　　为了支持云计算虚拟化、动态化、关联性、自动化的服务要求，整个云计算系统需要有一个统一的操作运行管理平台，能够对云服务进行端到端自动化部署，同时快速响应资源调度与业务变更的服务需求(如图2所示)。

　　图2 云计算的管理目标

　　统一的服务平台能够屏蔽云服务供应层面对底层不同架构的差异，使得用户或业务运营部门聚焦在服务层面，不必关注云计算资源(计算、网络、存储)本身的技术属性。

　　在自动化响应的管理关联结构上，云服务的提供需要将业务需求转换为对基础资源的部署要求，并形成相应的底层配置下发到不同的设备上，同时在服务变更(包括容灾、虚拟机迁移、扩展等资源的操作与调度)过程中，能够全方位调整底层设备的配置、功能、对接，以匹配业务需求。

　　三、如何选择合理的运行管理模型

　　模式一：集中统一的云计算运行管理

　　为了实现灵活的云计算服务，有些人提出了一种以统一集中的方式进行数据中心基础架构的运行管理模式(如图3所示)。这种模式下，云的操作管理平台能够对计算、存储、网络进行整合，在用户操作平面上形成单一的界面，在逻辑结构、运行结构上很清晰，管理层次少。

　　这种结构虽然在一定程度上实现统一的业务部署、基础资源的自动化调度，但局限性很明显。不同的IT系统有其固有的专业性，网络、计算、存储各个系统的监控运行、故障处理、软硬件升级、容量与规划完全不同，要在一个管控系统中既做到业务的统一，又做到基础管理的全面，不仅对这个系统本身的规模、复杂性、功能性、专业性提出了挑战，而且对于支撑管理运行的团队，也在操作配合、知识体系、专业交叉上产生了巨大的复杂度。

　　即使是一个厂家能够以极高的专业程度整合多个基础资源的运行管理到这样的统一系统，这个系统也必将非常巨大、复杂，其本身的运行维护也会存在极大难度。

　　模式二：双属式管理

　　第二种模型是双属式管理模型。如图4所示，在类似第一种模型的架构下，除了统一的运行管理平台，在计算、存储、网络各个系统中集成各自专业的管理系统。相比模型一，模型二有极大的增强，不仅可以简化统一运行管理平台的复杂度，又引入了传统成熟的运维管理方式，并分离了云计算的服务运营与基础架构管理，形成一个具有分工与协作的IT运行结构。

　　图4双属式管理模型

　　但这种模式的不足在于，对底层物理设备而言，存在两套指令系统：供应云服务的统一管理平台和独立的运维系统，如果存在操作上的偏差，需要这两套系统之间预先定义或确定一个优先顺序，否则在某些条件下将导致因不同系统的指令冲突造成服务的异常。同时，对于基础设备来说，两套指令系统的调用接口或协议也可能完全不同，甚至由于当前标准化的不足，针对不同的云管理平台有不同的定制化要求，带来了基础设备运行与设计上的复杂。

　　模式三：三层式管理

　　第三种模型是三层式管理模型。如图5所示，统一的云管理平台运行在一个逻辑层面(TopTier)，向云计算用户提供服务界面、云服务供应操作，不直接管理和操作底层设备。中间层(MiddleTier)是基础资源操作管理层，接受来自上层的云服务调用，并转换为针对底层设备的配置操作，中间层同时作为专业化系统对基础设备执行运行、维护、监管等功能。最下层为基础设备层面(InfrastructureTier)，是计算、网络、存储等基础云计算资源连通运行形成的物理层，接收来自上层的指令而运行和提供服务。

　　图5三层式管理模型

　　对于三层式模型，中间管理层统一了来自云服务管理平台的指令和自身的运维变更指令，形成一致的操作集下发，保证了操作的统一性。特别是对云计算而言，上层服务的部署、变化总是会涉及到底层多个系统之间的相互关联性变化，如虚拟机动态计算的特点使得其网络位置发生变化，存储资源也会因为数据迁移产生位置变更，这都涉及到计算、网络、存储各个对象之间的信息交互、协议通告、连接性检查等处理，以保证云服务的连续性与持续性。数据的流转与基础协议交互发生在第三个平面，但是在中间层不同资源的管理控制系统之间也主动进行信息传递，如虚拟机管理系统与网管系统之间交互计算迁移、状态与位置等信息，这使云服务的管理过程更为精确和可控，能够实现全部IT基础资源之间的关联性，并使得云计算的部署逐步走向更为完善的自动化。

　　三层管理模式更进一步的好处是，中间管理层作为对基础资源层面的指令层，因其完全由软件构成，具有需求变化的能力，即能够封装多种来自服务层面、异构系统之间的互操作信息，形成下层易执行的指令下发到基础设备上。如图6所示，每一种基础资源与其管理软件构成了一个灵活的按需变化的IT系统，它们对外的变化接口主要由管理软件来实现，当前通用的SOAP/RESTful等接口已经广泛用于软件系统之间的调用，以EVB技术实现为例：网络与网管之间完全紧耦合实现网络系统内部的运行控制管理，虚拟管理中心与服务器虚拟化系统之间完全紧耦合实现虚拟计算内部的运行控制管理;在Infrastructure Tier层面，网络与虚拟机系统之间通过标准技术EVB来实现数据互通与协议交互，这是整个云计算得以实现自动化、动态性、关联性的基础互通标准要求。而在控制层，网管系统与虚拟管理中心则通过SOAP/RESTful接口方式可以灵活定义这两种异构系统之间要求传递的信息(虚拟机标识、业务类型、网络标记、网络属性等)，从而实现了整个云计算系统的底层数据流转、控制层面业务属性流转。

　　图6异构系统之间的灵活接口方式

　　三种模型的对比小结

　　就目前国内用户应用情况而言，用户对计算、网络、存储分离的管理运行已经形成很好的经验，这在云计算环境下依然是很好的借鉴;在考虑向云计算转型/演进的架构上，服务交付与IT运行可能是相互独立，但又是前者依赖后者、后者以前者为目标的业务方式，这就要求云的管理运行架构既要有很大的灵活性，又要有对基础层面控制的精准性。模型一是当前很多用户认为很自然的结构，因为这个模型很含糊地掩盖了云服务与云基础架构运行的差别，模型二与模型三则展开了云计算的运行框架要求，同时还融合了传统IT的运行管理模式，使得用户的IT模式以渐进方式迁移到云服务。

　　四、结束语

　　适用的数据中心管理运行模型，不仅可以使业务模型清晰可靠，并能极大提升业务运行能力，使得传统数据中心的运行机制得到重用。但是，不同的云计算服务模式有其自身特点，基于自身的运行能力、已有系统的要求，选择并演进到适合每个云计算数据中心适用的模式，需要用户、厂家、服务供应商持续的适配、调整才能优化形成。