图片 10

读书笔记,云总括情状下数据主导管理运营研讨

图片 1

目前市场对一款产品是否是,没有明显的界定。因为云本来就没有一个标准。

图4双属式管理模型

传统IT的问题

互联网以及智能终端的普及,让信息得到了爆发性的增长,那么对IT基础架构(计算、存储、网络)来说,正在快速被饱和。

我们可以看看传统IT怎么运作的?比如运营商部门分析出网页游戏业务会有20%的增长,所以需要扩容,比如增加Web服务器、数据库服务器、存储系统的数量或容量,然后需要采购设备,遵循一系列的流程,这样周期非常的长,甚至慢于业务的变化周期。

但是另外一个部们的在线视频业务因为业绩不好,利用率不足60%。

当然最原始的想法是将在线视频业务的的40%余量分配给网游部门,不过会存在大量的技术风险。比如两种业务部署在同一个操作系统,会增加业务的粘度,不利于运维,然是如果把业务部署在不同的服务器上,更不利于运维。

加上现在数据中心中存在不同的协议、不同厂商的设备,如果靠手动来部署、管理和回收资源,效率低而且容易错,业务上线的速度也不快。

我们总结一下,传统的IT系统存在三个问题:

  • 业务部署周期长

  • 资源不能充分回收利用,存在孤岛

  • 手动部署无法满足需求。

这就痛点。

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

Micro、Mini、Normal、Huge、Grid弹性数据中心

弹性核或者软数据中心:将若干刀片与高密度的磁盘柜以及微型交换机打包到一个或者几个机柜里面,再覆盖以弹性层,比如虚拟机管理系统以及分布式存储系统,将这样一个微型弹性软核心做为一个可提供IaaS服务的整体交付给用户。

或者再在这个软核上覆盖一层业务展现于管理层,直接交付到SaaS层。一柜或者数柜交付的弹性基础设施,可以称为Micro
Cloud

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

系统架构变化

要解决之前提到的业务部署周期长,无法实现自动化,资源不能方便的回收和复用等,最容易想到的技术手段自然是虚拟化。

服务器虚拟化,即虚拟机系统,充分利用了资源,再加上Vmotion,DRS(Distrubted
Resource Scheduler)等技术,极大的增加了部署灵活性和资源均衡性。

我们来看看部署了虚拟机以后对之前的问题带来的变化。

  • 资源充分利用问题:旧业务余量会自动回收,新业务所需的应用可以直接以虚拟机的形式部署在物理机,因为操作系统各用各的,粘合影响得以避免。

  • 上线业务周期长的问题:部署虚拟机消耗的时间比物理机少了很多,上线速度加快

  • 手动部署问题:使用一种资源自动化分配和回收平台来解决自动化部署问题。

那么所谓虚拟化,其实就是在传统的数据中心上加上一个弹性层,这样整个数据中心就变成了软数据中心了。

如果还能做到部署回收自动化、可度量化、服务化、可运营的数据中心,则就是一个云数据中心了。

综上所述,云系统中重要的角色有:

  • 虚拟化

  • 集群化

  • 自动化:实现资源自动部署、调度、分配、回收的管理者

    • 对内可以与其他组件进行通信,管理资源
    • 对外可以响应业务部署的需求,并且将这些需求转化为对内的资源调度
      这个模块综合起来就是“自动化”。
  • 可度量化:
    也就是用户用了什么资源,为期多少时间,耗费多少成本,毛利率几何,报价几合可以精确度量、定价。

纵观云发展的过程中,说不清到底是先有云这种商业模式还是先有云这种技术架构的,两者其实是相互催生、相辅相成。

回顾存储系统的技术发展过程。

  • 最开始的时候,存储系统只需要关心数据存储,只要提供一块空间,怎么管,怎么用,底层是不关心的,

  • 后来,存储系统开始注重数据管理,开发了诸如快照、重删、容灾等功能。

  • 再后来,又到了数据运营阶段,还关心数据怎么的问题,此时需要更贴近用户的应用,注重业务展现。

图片 2

image.png

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

云的缺点

在看云的缺点之前先看一下云的优点:

  • 避免资源的浪费:

  • 节能

  • 角色转变

存在的问题:

  • 稳定性和安全性:如何解决两个存储资源互通的问题,如何才能保证完全隔离。

  • 平台迁移
    怎么样才能在不影响业务的前提下迁移到云平台上。

  • 不兼容的问题:不同云服务商提供的架构不同,接口也不同。

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

目前云计算、云存储、云备份等技术可谓是铺天盖地,其中不乏有很多是浑水摸鱼的,本来没有多少云的性质,只是打着云的旗号来炒作而已。

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

实例说云

下面使用3Tera Applogic的例子来说一下IaaS层

3Tera的IaaS平台名为Applogic,是一不可以实现IaaS功能的软件虚拟化平台。我们可以看一下它的底层架构:

主要分为4大层次:

  • 硬件层:

    本层包含服务器、存储、网络设施等。

    Applogic不要求底层存储必须是基于SAN的,可以是本地IDE。若干服务器通过千兆以太网连接起来,形成集群。

    然后在这个有限且分配不灵活的资源池上,实现一种管理方便、使用方便、资源灵活分配的虚拟化层。

  • 分布式核心虚拟化层(Applogic OS):

    • 计算虚拟化:Distributed Virtual Machine Manager(DVM)

    本层的核心是虚拟机技术,通过Hypervisor引擎来虚拟化成多个主机,比如说VMware的ESX
    Server就是实现这个目的的。只不过Applogic使用的是Xen虚拟机平台。

    • 存储虚拟化:Global Volume Store(GVS)子层:

    Applogic使用的是自研分布式文件系统,在这个文件系统之上虚拟出Volume,而且Volume可以Mirror、Clone、Snapshot等。

    每个Volume在多个物理主机上有镜像以解决HA问题,并且可以提升读性能。
    而这些Volume对于最终的虚拟机就是裸磁盘,在这个虚拟化层上,每个节点将自己的本地存储空间贡献出来,所有节点的存储被整合起来进行虚拟化。

    • 网络资源虚拟化:Logical Connection
      Manager(LCM):将物理网络搞成虚拟网络
  • 一次性基础设施虚拟层

    所谓一次性基础设施,其实就是虚拟机可以按需创建。每个应用程序可以分配一个独立基础设施,包括防火墙、负载均衡、Web服务器、数据库服务器等。当要删除应用程序的时候,可以直接把虚拟机删除了。

    这些角色可以虚拟成一个个对象,在图形界面使用鼠标拖拽的方式建立对象

![](https://upload-images.jianshu.io/upload_images/1323506-a090957e0a02163a.png)

image.png

上图创建了一个防火墙、负载均衡、2台Web防火墙、数据库服务器,整个网格中的Volume按照Application进行隔离,不同的Application只能看到自己的Volume。

防火墙、负载均衡、WebServer之间互联的IP用户不需要关心,系统**自动分配**,唯一需要配置的是整体Application的IP地址信息。
  • 网络控制层和应用程序管理层

    以Application为单位向用户交付。

Applogic带来的革命是把复杂的底层硬件变得简单,通过拖拽对象来状态自己的基础架构,最终以适合某中Application运行的整体服务器&存储&网络来交付。

图片 3

image.png

二、云计算管理的目标

云其实是商业模式

不过上面的说法只是云诞生的一部分理由,实际上最初的云,实际是一种商业模式,当商业模式与计算机技术结合之后,才产生了云这个代名词。这也是云没有外在的像技术一样严格的标准的原因。

图片 4

image.png

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

云的是怎么来的

国外在指代一堆设备的时候,一般使用Cluster这个词,而中文翻译一般是“簇”或者“集群”。云这个词来源已不可考,也许是某个人在讲授PPT的时候,顺口说了一句”The
Servers in the cloud”的吧,这样Cloud这个词就诞生了。

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

公有云和私有云

现在我们已经有了一个云化的数据中心了,那么可以按照数据中心的是对企业内部开放服务还是给任何人开放服务来分为私有云和共有云:

  • 私有云:数据中心对企业内部开发,提供云服务,比如存储空间申请、企业应用系统的快速部署等。

  • 公有云:对外营业,通过互联网提供各种云服务。

  • 私有云让企业IT部门角色转变

    传统的IT部门是一个支撑部门,始终处于业务部门的牵引之下,所有的采购、经费申请必须以业务需求为前提。

    那么怎么提升IT部门的地位,只要也得与业务部门处于平等的地位。云中的“服务”两字正好满足了这种需求,比如IT部门可以通过建立规范的资源申请流程,然后建立电子工单审批系统,只有通过审批以后才提供对应的服务。还可以统计某个部门在某段时间内使用了多少IT资源,消耗了多少成本。

    这样IT部门成为一个独立的服务角色,其他部门向IT部门申请资源的时候,是以协商的态度而不是强势的牵制的态度,而且因为资源可度量了,IT部门可以做出合理的预测,申请后续经费等资源变得更有说服性。

  • 公有云受制于互联网带宽发展

    如今互联网的接入速度还是比较低的,大量用户的速度还是1Mbps,也就是只有100KB/s的吞吐量的接入速度。此时,若给他一个iSCSI协议访问的存储空间是不现实的,最多提供网盘这样的上传下载服务。

    常用的SaaS服务(网页、聊天、视频、网盘等)基本上可以基于低速网络,但是IaaS就困难了,比如访问虚拟机的时候,如果不是用xshell这种方式,而是使用虚拟桌面登录,1Mbps非常勉强。而且,如果要安装软件,还得把安装包传上去。

综上所述,云目前最能被广泛推进的地方就是新建数据中心,企业兴建私有云,运营商兴建混合云

图片 5

image.png

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

云之后的发展

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

对云的几种认识

目前人们对云的认识基本就有4种不同的观点:云即设备、云即集群、云即IT系统、云即服务

  • 云即设备:

    这是最原始的观点,也就是所谓的云只是指代一堆设备,因为没有设备的支撑,哪来的云。

  • 云即集群:

    光有设备还不行,还需要这堆设备有机的联系起来,相互协同,对外呈现为一个群,这是在“云即设备”上的一次发展。

  • 云即IT系统:

    上面说到的集群,也只是一堆服务器放在一起,可以协作,若要进一步发展,需要加上软件作为灵魂,比如某企业的IT系统。

  • 云即服务:

    IT系统一般是用来支撑企业的业务的,但是我们能不能通过他来盈利呢?这就涉及到商业模式上面了。主要有如下几种模式:

    • 直接卖了:

    如果像卖房子一样,受众很小,因为需要购买一整套IT系统的人很少。

    • 租出去:

    这就如同租房子一样,受众相对于卖房子大很多。但是盈利慢

    • 利用IT系统来运营某种业务,用来赚钱:

    这种方式受众更大,像邮箱、网页、博客,几乎全民都是客户,所以盈利面很大。这样看来,能提供某种形式IT服务的一整套IT系统都是云。从这个角度,所有的互联网运营商,比如各大网站,都是云运营商。

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

云系统架构及组成

下图为云具体的架构:

图片 6

image.png

分为如下几个层次

  • 物理架构层:比如供电、散热等

  • 基础IT架构层:包括网络、存储、服务器等

    需要注意的是这些服务器与存储设备不是孤岛,他们会组成集群,上面搭载虚拟化,并进行自动化的管理。

  • 基础架构/集群管理层

    有了集群还不够,需要在上面覆盖虚拟化层来增加系统的弹性

    对于服务器就是VMware这样的虚拟机平台。对于存储,就只能分布式文件系统或者分布式卷管理系统才能满足这种需求。

  • 资源部署层:

    现在我们已经可以得到一个网络、服务器、存储的集群,还需要一个用来管理和驱动集群的角色。

    比如VMware的Vsphere可以进行计算资源的包裹,分布式系统可以进行存储资源的包裹。

    利用VSphere提供的Vmotion与DRS可以将虚拟机在集群节点中灵活移动,自动资源动态分配和回收。

  • 中间件层

    应用层与资源层需要一个中间层来适配,这就是中间件层

  • 应用引擎层

    这一层需要提供一个通用的业务开发平台,可以实现统一发布。

  • 业务展现与运营层

    现在数据中心的架构已经具有集群化、虚拟化、自动化的形态了,但是这只是对自己有用,对用户来说,他们不用关心底层用不用集群或者虚拟化,只关心是否能得到快速的服务和响应

    所以我们还需要一个业务展现界面,这就是云服务。

图片 7

image.png

那么出租数据中心其实可以在以下几个层次中进行:

  • 基础设施即服务(IaaS)

    所谓基础设施指的是云系统中的硬件设施如服务器、网络、存储。所以IaaS只是提供硬件平台,具体的计算任务由用户自行部署。

    • 如何卖存储空间:

    可以有多种方式,比如卖裸空间、文件存储空间等。
    裸空间就是最终用户看到的是一块硬盘,所有协议当然首选ISCSI,以便跨越IP网络,这样用户可以通过ISCSI
    Initiator连接云提供商的ISCSI Target,然后就可以获得多个LUN。

    对于云中存储系统,精简重删这些特性应该是必须的,可以降低不必要的空间占用,而动态分级可以进一步节省存储成本。

    • 如何卖服务器、虚拟机

    虚拟机平台需要考虑几种功能:
    一是动态迁移,即虚拟机可以在不影响应用系统的情况下在物理机之间进行迁移。

    二是资源动态分配调度,

    三是管理方便。

    Amazon在IaaS提供两个产品:弹性计算云(Elastic Compute Cloud ,
    EC2)和简单存储服务(Simple Storage Service
    ,S3),分别对应了主机计算集群和存储集群

  • 平台即服务

    相对于IaaS,PaaS屏蔽而不出租基础架构,转而出租更高一层的软件平台。用户可以通过这个平台制作应用。因为这个平台是一种运行与硬件集群中的软件,用户实际上相当于租用了计算业务。

  • 软件即服务

    SaaS是云服务中的最外层,直接出售业务级别的内容。比如Web网页等。

图片 8

谁催生了云

谁催生了云?当然是需求

图片 9

给云下个定义

那么云目前最主流的定义是啥?

上面提到过,设备组成集群,集群搭上软件称为IT系统,IT系统用来服务,好了我们可以把之前的观点结合起来下个定义:

云是一个可运营的IT系统,

但是这个定义缺少最关键的东西,就是资源迅速灵活地部署和回收。所以云当前最主流的定义为:

云是一个智能IT系统,它是:

  • 可运营的

  • 可以迅速灵活部署

  • 可迅速回收资源的

也就是

云是一个可运营的,迅速灵活部署和回收资源的智能IT系统。

那么云应该具有如下性质:

  • 云提供商拥有一定规模的硬件基础(计算、存储、网络)

  • 作为服务进行交易,而不是实物交易,客户只是租用资源

也就是云其实是一种商业模式,如果认为只有底层使用了硬件集群和虚拟化技术的系统才是云这种观点是非常狭隘的。

图片 10

image.png

图片 11

云的本质

云本质是一种服务,而不是一种物质,正因为此,它必须基于物质才能显示功效,《易经》有云:“形而上者谓之道,形而下者谓之器”。所以下器者,谓之服务器+存储+部署管理软件;上道者,谓之“云”。所以云是一种道,是一种方式和方法,而不是某种设备,某个软件,当然云需要由硬件+软件来承载而已。

所以,云和速度性能没有直接关系。云本身不一定就是一个高速高冗余的东西,而是说底层硬件一般使用并行计算集群和存储集群,在这个基础上,云才能表现出更大的效能。

而且云也不是为了提速而生,它的主要目的是廉价高效的利用资源并降低硬件的应用成本和管理成本。

其实云早就存在了,只有近两年才被炒作起来,互联网服务器就是云服务,所以有人提出IT服务即云,Everything
as a service。

其实在40年前,我们还是用集中分时计算,随后到了世纪相交的纪念,用户各自购买基础架构进行计算和存储,然后又逐渐回到了集中计算的时代,实际上这既不是进化,又不是退化,是“分久必合,合久必分。万物皆在轮回中不断发展,到一定程度就回到当初的形态,但是承载它的物质是连续不断的提升的。所轮回的只是其上的那层能量,谓之道。

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

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

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

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

三种模型的对比小结

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

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

模式三:三层式管理

图片 12

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

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

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

图片 13

模式二:双属式管理

图5三层式管理模型

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

图3集中统一的云计算运行管理模型

图2 云计算的管理目标

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

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

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

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

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

四、结束语