CN102857363A

CN102857363A - 一种虚拟网络的自主管理系统和方法

Info

Publication number: CN102857363A
Application number: CN2012101377716A
Authority: CN
Inventors: 汤传斌; 朱勤
Original assignee: Transoft Network Sci-Tech (shanghai) Co Ltd
Current assignee: Transoft Network Sci-Tech (shanghai) Co Ltd
Priority date: 2012-05-04
Filing date: 2012-05-04
Publication date: 2013-01-02
Anticipated expiration: 2032-05-04
Also published as: US9659251B2; CN102857363B; WO2014015697A1; US20160078342A1

Abstract

本发明公开了一种虚拟网络的自主管理系统和方法，本发明涉及在自主计算领域中的三项基础发明：多循环自主管理者、抢占性接触点（即抢占性传感器和效应器）、硬件资源软件化（把硬件功能抽象化和虚拟化）的系统与方法；在分布式网络领域的业务交付虚拟网络，和应用保障系统和方法；以及融合以上两个领域的发明，即自主管理的虚拟网络，使提供业务交付的虚拟网络的管理，实现n层ACRA架构的系统与方法。

Description

一种虚拟网络的自主管理系统和方法

技术领域

本发明涉及自主计算和虚拟网络的领域。更具体地，本发明涉及在自主计算领域中的三项基础发明：多循环自主管理、抢占性接触点、硬件资源软件化的系统与方法；在分布式网络领域的业务交付虚拟网络，和应用保障系统和方法；以及融合以上两个领域的发明，即自主管理的虚拟网络，使提供业务交付的虚拟网络的管理，实现n层ACRA（Autonomic Computing Reference Architecture）架构的系统与方法。

背景技术

自主管理

自主计算（autonomic computing）又称自治计算,是美国IBM公司的P.Horn于2001年10月在Autonomic Computing:IBM’s Perspective on the State of InformationTechnology一文中提出的一种新概念及参考标准。自主计算被广泛地认为是新一代的集成计算机技术。在计算机网络领域,该技术的应用能够使网络设备以及网络上的软件在很少或者没有人干预的情况下对自身进行管理。

“自主”这个术语源神经科学理论。自主神经系统是广泛分布于内脏器官的相互连接的神经元网络。自主神经系统通过交感和副交感神经的协调作用,可“自主地”调节人体内的各种参数(体温、心律、血压、血糖水平等),并使之保持在一定的范围内。

关于自主计算的定义,目前的看法尚不统一,根据Kephart的The Vision ofAutonomic Computing一文一般认为自主计算系统应该具有如下4个主要特性:自我配置(self-configuration)、自我修复(self-healing)、自我保护(self-protection)和自我优化(self-optimization)。其中,自配置是指系统能够根据高层策略自动配置自己,以适应环境的变化;自修复是指当软/硬件发生故障或异常时,系统能够自动地发现、诊断和修复故障;自保护是指当系统遇到恶意攻击或者由于自修复措施无效而发生连串失败时,能够从整体上保护自己,同时,它也可以根据来自传感器的相关报告预测问题,并采取措施加以预防;自优化是指系统能够不断寻找方法来改善性能、降低消耗。根据Salehie的博士学位论文A Quality-Driven Approach to Enable Decision-Making in Self-Adaptive Software统计得知,大多数的自主计算系统仅仅针对其中1个或2个主要特性。所以并不是说要同时具有上述4个主要特性才能被称作自主计算系统。

自主计算系统(autonomic computing system)由若干相互联系的自主元素(autonomicelement)组成。在策略(policy)的指导下,这些自主元素在实现内部自适应的同时(即局部自主管理),通过交互和协作实现整个系统的自适应(即全局自主管理)。（有关“自主元素”与“自主管理者”这两者定义的差异，请看图2B的说明。）

在一个自主系统中，各个自主元素分工协作,以实现一个共同的目标。IBM的白皮书An Architectural Blueprint for Autonomic Computing描述了一个有普适性的自主系统架构,称做Autonomic Computing Reference Architecture(ACRA),请参阅图1。

ACRA自主系统架构将自主计算系统分为三层:

在底层的是系统组件或被管资源。这些被管的资源可以是任何类型的资源，包括硬件或软件。被管元素既可以是各种内部资源,包括数据库、服务器、路由器、应用模块、Web服务或虚拟机器等,也可以是其他自主元素,这些资源可以会有一些嵌入式(embedded)，自主管理的属性（请参阅图1，一个自我管理的资源显示在底层左侧）。每个被管理资源一般都提供标准化的接口。每个标准化的接口对应于一个传感器(sensor)/效应器(effector)组。单个自主元素一方面通过自主管理者管理内部资源,另一方面,它向外提供标准接口(传感器/效应器组)接受管理,包括接受IT管理者指定的策略以及与其他自主元素的协作信息等。例如负责全局编排的父自主元素可以管理多个下级的子自主元素。

中间层包含资源管理器往往分为四类：自我配置，自我修复，自我优化和自我保护。每个资源可能有一个或多个资源管理器，每个管理器实现自己的控制循环。

顶层包含有协调各种资源管理器的统筹管理器。这些统筹管理器本身具有自主管理元素的结构，通过系统范围的大控制循环，实现某些全局、系统级的管理目标,达到全系统的自主管理。请参见图1,左侧所示的是人工管理器，通过一个集成控制台它给IT专业人员提供了一个通用的系统管理界面。请参见图1,右侧所示的是一个知识库。人工的和自主的管理器都可以从知识库获取和分享有关系统的所有知识。

就目前自主计算的发展状况来看(根据Salehie的博士学位论文内的例举),绝大多数的自主管理系统是应用于实体(物理)系统之上的,和虚拟化相结合的实例几乎没有。而本发明的一种自主管理系统(本身)的虚拟化方法,则是本发明的首创。

有关自主管理的方法，虽然Grell等人在US2010/0287361 10的专利中利用复杂事件处理（Complex Event Processing,即CEP）引擎来处理Root Cause Analysis（RCA），但CEP引擎其实可以动态创建和动态撤除任何自主管理instance的特性,来实现ACRA自主系统架构中中间层内各个自主元素的虚拟化，应用领域也未必只局限于RCA。而利用复杂事件处理技术CEP来构建自主元素的自主管理者这一方法,也不见著于我们所知的以往的研究著述或专利中,所以本发明的新颖性和创造性也体现于自主管理系统的CEP设计方法之中。

虚拟网络

前面所提到的虚拟化，应该泛指虚拟的计算资源（例如虚拟机）、网络资源（例如虚拟交换机）和虚拟存储，而非仅限于熟悉此领域的人所知的被虚拟化了的操作系统（也就是虚拟机）。而包含这些资源的系统，在分布式的情况下，也经常包含计算、网络和存储的物理（非虚拟）资源。例如，一个银行的应用开发小组可能使用少许虚拟和物理资源来开发，并做模拟这些资源的测试。但在实际的生产环境中，顾虑到计算资源的性能可能因虚拟化而减低，所以完全不用虚拟资源。由是，我们定义“虚拟网络（Virtual Networking）”这一名词为：任何使用物理且／或虚拟的计算资源、网络资源、和存储资源的分布式系统。“虚拟网络管理（Virtual Networking Management）”的系统可以是类似符合以下标准的系统：TMN、eTOM、NGOSS、TMForum或DMTF。

虚拟网络管理虽然有上述的多方面的标准，但真正实用的创新方法还不多见。熟悉这一领域的人都知道，操作系统虚拟化例如VMWare、Xen或Linux KVM的技术可以提高服务器使用率，节省成本，但面对大规模的数据中心资源，这些技术并不足以完全“自动化（automation）”用户的复杂业务。而即使能够使用自动化来提高虚拟网络经过整合后的大规模资源的效率，又未必能保障（Assurance）不会过分使用资源，造成“超载（overload）”情况。

虚拟网络的管理系统包含多个子系统：应用规划设计系统（ApplicationPlanning/Design System）、应用交付系统（Application Delivery System）、还有一个子系统，叫做应用保障系统(Application Assurance System)，能纾解上述超载情况。就虚拟网络下应用保障的方法而言，在王彦新等人的中国专利201010183844.6“通过总线架构构建虚拟机监控器的方法和性能服务框架”里的性能服务框架系统本身，并没有提及性能数据的监听与收集。而在汤传斌等人的中国专利201110141642.X“一种基于硬件基础工具监视虚拟化系统性能的架构及方法”则单独提出了性能数据的监听与收集。此二专利并未互相引用，更遑论与自主管理系统的结合，以及这种结合的实现方法。

自主管理的虚拟网络

有关自主管理在虚拟网络的应用，Barkai等人的美国专利US6941362B2陈述了一般网络环境下RCA的处理方法，但并未使用自主管理的概念，也未提及这种网络环境包含了任何虚拟资源。因此，本发明的自主管理系统和方法，与在被自动化的虚拟网络管理系统（特别是应用保障系统）的结合，从未在其它专利出现过。

发明内容

本发明涉及自主计算和虚拟网络的领域。更具体地，本发明涉及在自主计算领域中的三项基础发明：多循环自主管理、抢占性接触点、硬件资源软件化的系统与方法；在分布式网络领域的业务交付虚拟网络，和应用保障系统和方法；以及融合以上两个领域的发明，即自主管理的虚拟网络，使提供业务交付的虚拟网络的管理，实现n层ACRA架构的系统与方法。

在自主计算领域中的三项基础发明

这三项基础发明是：（1）多循环自主管理系统：其监视、分析、计划、执行这四个MAPE过程可以在其间循环多次。多循环自主管理使用复杂事件过程来处理，其软件模块称为Event Processing Agent,EPA。而EPA可以使用智能的方法实现多循环的4个MAPE环节。（2）抢占性的自主管理系统的接触点：接触点也就是传感器和效应器，可以利用硬件的性能监视工具，运行在环0的权限里，具有抢占性，可以预警可能的故障而及早防范。（3）物理资源软件化：物理资源在物理POD中被重组，当资源发生变化，该事件经由虚拟有限状态机计算其能力，知晓因应的资源调度行动，因而可以把资源的使用优化。

自主管理者本身可以被虚拟化，其意义为频繁的自主管理软件更新/部署可以实时，并可由统筹管理器集中管理。方法是实时拆分和重组自主管理组件，和/或将安装好自主管理软件（包括策略和规则）的OS镜像，同步到资源管理器及被管理的主机。其次，上述环0的抢占性接触点根本上克服了过去“监视和被监视软件运行在同一权限，因而无法预警”的缺陷，就自主管理而言意义不菲。更有甚之，硬件也可以被虚拟化（或称软件化，但这并不是操作系统虚拟化！），这是熟悉本领域的人不容易想到的。

分布式网络领域的发明

本发明对虚拟网络的业务交付，使用自动化方法，有别于一般的eTOM(EnhancedTelecom Operation Map),NGOSS(New Generation Operations Software and Support),TM Forum(Telecom Management Forum)的方法。而对于虚拟网络下的应用保障，使用网络子系统：应用保障系统(Application Assurance System)的方法。从用户角度来看,网络应用保障系统是监视及维持用户应用程序正常运行的一个工具。它不但管理各种物理设备和用户应用程序,还管理各种虚拟设备。本发明的实用可以体现在该系统的虚拟设备管理部分。

自主管理的虚拟网络的发明

本发明融合以上两个领域的发明，而有其自身的特性。使用会话协议，可以保存/恢复荷载状态；使用集群拓扑，可控制海量的主机。此外，自主管理的系统及方法可以应用在下述五个层次：物理POD，软件化服务，逻辑POD，业务交付平台，和用户代理。

以上各种发明概念均可分为系统的发明和方法的发明。详情见下表：

本发明的技术方案为：本发明揭示了一种设计和构造多循环自主管理者的系统，包括设计装置和构造装置，其中：

设计装置，所述设计装置在分析和规划这两部分的中间增加至少一个额外的循环，多循环自主管理者是对经典的自主元素模型中的自主管理者的一种扩展；

构造装置，所述多循环自主管理者用诊断流程图表示故障诊断工作的步骤，所述故障诊断工作是循环往复多次“产生假设→进行调查→发现结果→得出结论”的过程，最终得出最后故障诊断结论；

其中所述多循环自主管理者在自主计算参考架构下，形成含有经典与非经典自主元素的混合式自主计算参考架构。

本发明还揭示了一种多循环自主管理者的实现方法，包括：

将诊断流程图中的每一步骤作为一个事件，将诊断流程图中的各个步骤运行之间的连接作为一个活动，并据此将所述诊断流程图转换成事件驱动流程方框图；

将所述事件驱动流程方框图中的事件映射到一个自主管理者中，以使该自主管理者的分析和规划部分都可以用一组规则来表示，其中所述规则由复杂事件处理技术实现，所述自主管理者在自主计算参考架构下，形成混合式自主计算参考架构，所述自主管理者的每一部分包括复杂事件处理引擎的实例，每个实例中可以包含有多条规则。

根据本发明的多循环自主管理者的实现方法的一实施例，所述自主管理者通过事件驱动方法实现，所述复杂事件处理引擎的每个实例是一个事件处理代理，所述自主管理者是由四个事件处理代理连接而成，由所述事件处理代理来构建的所述自主管理者在分析和规划这两部分中间增加了至少一个额外的循环，所述自主管理者是对经典的自主元素模型中的自主管理者的一种扩展。

根据本发明的多循环自主管理者的实现方法的一实施例，所述多循环自主管理者保存、搜索事件处理代理规则库里的规则，保存过去的经验，并自动学习得到新规则；

监视器事件处理代理形成至少一个规则的事件列，保存在事件处理代理规则库中；

分析器事件处理代理搜索当前符合刺激的事件列，如果成功以分数匹配到最相似的假设，否则回到监视器；

计划器事件处理代理识别目标、目标参数，搜索符合目标与元状态的假设，如果成功则把失败经验存入规则库而且以分数匹配到最相似的修复计划，否则回到分析器；

执行器事件处理代理搜索符合策略的修复计划，如果成功则利用分数匹配到最佳执行计划，否则回到计划器。

根据本发明的多循环自主管理者的实现方法的一实施例，所述混合式自主计算参考架构包括底层、中间层和顶层，其中所述混合式自主计算参考架构的底层包含有虚拟的和物理的网络设备,所述虚拟的和物理的网络设备作为被管资源存在所述混合式自主计算参考架构中,部份被管资源本身就含有自我管理的属性；

所述自主计算参考架构的中间层则是大量的由事件处理代理来构建自主管理者的自主元素，每个自主元素代表一项原本由IT人工进行的管理工作,所述这些自主元素作为资源管理器存在于混合式自主计算参考架构中,所述自主元素实现自配置、自优化和自修复中的某一类任务；

所述自主计算参考架构的顶层包含有统筹各种中间层资源管理器的统筹管理器，所述统筹管理器控制全局系统范围的自主管理。

本发明还揭示了一种虚拟化的自主管理系统，所述虚拟化的自主管理系统包括：

镜像部署模块，自主管理者本身经由应用虚拟化的组件拆分和重组，直接部署在物理机或虚拟操作系统的镜像上，直接部署的传输使用串流技术，在镜像上的虚拟自主管理系统组件经由差分技术，随时在自主计算参考架构的底层、中间层、顶层这三层架构之间同步；

接触点模块，包括自主管理者的传感器和效应器，运行在被操作系统虚拟化的主机虚拟机监视器和硬件层里，具有主机虚拟机监视器底层环０的安全权限和抢占性，为即将造成故障而无抢占性的进程发出预警，进行预防措施；

硬件虚拟化模块，自主管理者利用硬件虚拟化管理物理和虚拟资源，硬件虚拟化利用软件化服务器中的虚拟有限状态机保存，搜索当前物理资源和逻辑资源的状态，所述自主计算参考架构的中间层资源管理器由各类自主管理者构成，所述资源管理器管理虚拟资源和物理资源,所述虚拟资源包括虚拟服务器、虚拟交换机、虚拟网卡，所述物理资源包括物理交换机。

所述镜像部署模块、所述接触点模块、所述硬件虚拟化模块为任何自主管理系统所实现，包括权利要求1的多循环自主管理系统。

本发明还揭示了一种具有抢占性权限的接触点系统，所述接触点包括传感器和效应器，运行在操作系统或虚拟机内核，具有内核环０的安全权限，其中：

所述传感器，接收从硬件传来的刺激时，判断可能的故障；

所述效应器，进入内核的中断服务例程，具有内核环０的安全权限和抢占性，控制内核级别环1-3的内存管理器、周边设备管理器和任务调度器，以终止、重启、改变时间片或活迁移运行在操作系统或虚拟机上无抢占性权限的进程。

本发明还揭示了一种智能的环0接触点实现方法，所述方法包括：

传感器实施进程级别的监视，使用多路复用的方法，以使被监视的事件数超过性能监视单元计数器数量的情况下仍可监视，传感器也实施系统级别的监视，包括监视转换后援缓冲器丢失、PCI总线延迟及流量、CPU停顿周期、内存访问延迟、设备访问延迟、和缓存指令停顿；

效应器将任务调度器的方法设置为成组方法，效应器在使用程序性规则迅速判断后，实现中断服务例程中断，控制任务调度器以停止、重启和停止分配时间片，直到高峰时间过去，当效应器运行在操作系统里时实现以上控制行动，而如果效应器运行在虚拟机里，则活迁移虚拟机。

根据本发明的智能的环0接触点实现方法的一实施例，所述方法还包括依赖于操作系统平台的方法：

将性能监视器硬件的驱动软件从Linux平台分离，移植到其它平台上。

本发明还揭示了一种将硬件资源软件化的服务方法，自主管理者拦截多个并发的请求，将请求映射到一个虚拟有限状态机，并使用虚拟有限状态机计算出物理资源的能力，把能力映射给物理机，最后物理机实现请求。

根据本发明的将硬件资源软件化的服务方法的一实施例，过程如下：

物理交付点的监视器侦测到硬件资源需要变化的事件后，将事件转发给软件化服务器；

软件化服务器的监视器接到该事件后，触发虚拟有限状态机执行器；

虚拟有限状态机执行器向虚拟有限状态机规则库查阅规则，并根据当前资源状态，判断系统是否有能力实现该事件的请求；

虚拟有限状态机执行器根据判断结果，变迁当前资源的状态，并执行行动；

软件化服务器获得当前状态和行动，并得知能力；

软件化服务器为了实现物理交付点资源的供应，提供新的数据和服务参数；

软件化服务器获得当前能力，并设置新的状态，状态的更新触发虚拟有限状态机执行器；

虚拟有限状态机执行器输入当前资源的状态、服务数据和服务参数，并从虚拟有限状态机规则库查阅新服务和参数；

虚拟有限状态机执行器判断出物理交付点应有的新进入服务，由服务模块将服务数据和服务参数传输给物理交付点；

物理交付点的服务模块完成新的供应，回应最初被拦截的请求。

本发明还揭示了一种软件化服务器的实现方法，所述实现方法包括：

物理交付点和软件化服务器形成一个客户端/服务器架构，按照自主管理的自主计算参考架构、软件化服务器的全局组件和客户端的物理交付点的当地组件呈一一对应，实现具有资源属性和状态的虚拟有限状态机管理信息库，虚拟有限状态机执行器，虚拟有限状态机规则库和/或虚拟有限状态机监视器；

软件化服务器是基于虚拟有限状态机对于内网和外网资源进行能力计算，其中虚拟有限状态机可以用于系统设计时或运行时；

虚拟有限状态机执行器根据满足资源状态、服务质量和虚拟有限状态机规则所建立的虚拟有限状态机模型方法计算能力、执行事件；

虚拟有限状态机规则引擎按照智能的多循环复杂事件处理方法，进行虚拟有限状态机规则库的存储、调整、和搜索；

虚拟有限状态机监视器使用智能的环0传感器和效应器监视虚拟有限状态机能力，防止过载或超出能力。

本发明还揭示了一种业务交付的虚拟网络系统，所述虚拟网络系统包括六个部分：

企业环境设计和规划装置，在业务环境下与业务程序管理办公互动的业务设计服务和与业务用户互动的业务订阅服务应用，修改增强电信运营图里有关业务的策略/承诺和基础设施的生命周期管理；

企业环境交付管理装置，在业务的离线逻辑环境中应用，修改增强电信运营图里的产品生命周期管理业务运营准备和支撑；

企业环境在线交付和运营保障装置，在业务的在线交付环境以及应用保障系统的业务管理部分应用，修改增强电信运营图里的业务合约履行和业务保障；

IT资源设计和规划装置，在系统管理员的资源设计服务中应用，修改增强电信运营图里有关资源的策略/承诺和基础设施的生命周期管理；

IT资源交付管理装置，在未分配的虚拟和物理资源中应用，修改增强电信运营图里的产品生命周期管理和资源运营准备和支撑；

IT资源在线交付和运营保障装置，在已分配虚拟和物理资源的在线交付环境以及应用保障系统的资源管理部分中应用，修改增强电信运营图里的资源合约履行和资源保障；其中已分配虚拟资源具有虚拟资源的独占和共享支持，所述虚拟资源汇聚不同位置、配置的物理资源，实现物理资源类型、部署无关化的资源融合，所述物理资源实现于企业业务划分的数据中心和物理资源网络，支持订阅交付，同时支持按空间分享和按时间分享物理资源，包括许多未分配和已分配的网络、存储、计算物理资源。

根据本发明的业务交付的虚拟网络系统的一实施例，所述虚拟资源汇聚不同位置、配置的物理资源，实现物理资源类型、部署无关化的资源融合；所述物理资源实现与企业业务划分的数据中心和物理资源网络，支持订阅交付，同时支持按空间分享和按时间分享的物理资源，包括许多未分配和已分配的网络、存储、计算物理资源。

本发明还揭示了一种业务交付虚拟网络系统的自动化方法，所述自动化方法包括：

用户业务调度供应：包括计算、存储、网络资源的需求设计服务、系统资源分析服务、虚拟资源预约和部署服务、进行虚拟资源调度供应，若资源能力不足，则进行服务质量和错误服务，最后进入业务交付服务；

虚拟资源调度供应：包括虚拟资源分配、配置、供应服务、软件化服务、进入物理资源调度供应，若资源能力不足，则进行服务质量和错误服务，最后进入业务交付服务；

物理资源调度供应：接收软件化服务的设置资源指令，实现资源多路复用、资源空间共享、资源通知传回软件化服务；

全面自动化服务：包括应用规划和应用部署、自动资源规划和运营，按业务动态供应资源，并自动映射资源至物理网络，且立即执行。

根据本发明的自动化方法的一实施例，所述业务交付服务包括：

处理接入过程：用户若是应用供应商，则将业务组件聚合，或者将应用接口公开；实现7层交换实现虚拟业务交付/实时业务域的自动化，并按照业务工厂所提供的规格建立逻辑业务；用户若是个人，则采用自助服务实现7层交换实现虚拟业务交付/实时业务域的自动化；

业务交付过程：在逻辑核心网上快速部署、卸载，但不碰触企业物理网、物理资源，业务运行在保障系统的监视下；

建立交付点过程：为计算、存储、网络的物理资源建立物理交付点，建立软件化服务器，融合数据中心的物理资源，形成交付点驱动，为每个业务环境建立逻辑交付点。

本发明还揭示了一种混合式保障系统，所述系统包括：

中央采集控制系统，相当于自主计算参考架构中间层资源管理器;

被管理资源主机以及主机上的代理，相当于底层被管资源上的四个性能MAPE服务组件：监视器、分析器、计划器、和执行器，以及两个接触点：传感器和效应器;以及

后台子系统，相当于集成控制台并具备有某些顶层的统筹管理器的功能。

根据本发明的自主管理的虚拟网络应用保障系统的一实施例，所述性能MAPE服务组件：运行的主机是集群的从机，即网络的叶结点，或是集群的主控主机，即非叶结点，抢占性/关键任务的政策和一般应用的政策均通过网络传输至任何节点；

所述分析器的规则包括硬件规则和应用规则，集群中的主控主机还可包括网络流量调节规则；

所述计划器里的负荷调整器，调整集群级别和事务级别的负荷，统筹全局系统的分析、当地应用的分析、并利用抢占性中断的优势，处理进程生命周期的管理；

执行器的各式政策执行点存在于虚机、虚拟机和多计算机切换器中，借助基数遍历器执行计划器下达的指令。

根据本发明的自主管理的虚拟网络应用保障系统的一实施例，如果主机实行操作系统虚拟化，

则监视器运行于虚拟机内和／或用户层，执行器运行于虚拟机内和／或用户层，虚拟机串口通道和Upcall/Hypercall形成两个通道，方便快速简短信息的传输,此二通道借助运行在虚机上的代理收集性能信息，执行决策。

本发明还揭示了一种使用自主管理的网络应用保障系统的实现方法，具有虚拟网络设备自主管理部分：

前台子系统实现相当于混合式自主计算参考架构中集成控制台加上统筹管理器的功能，所述功能中的告警管理、配置管理、性能管理实现了对中间层的自修复,、自配置和自优化三类自主元素的全局性管理，所述混合式自主计算参考架构顶层中的全局性管理被设计在前台子系统上；

中央采集控制系统实现相当于混合式自主计算参考架构中的中间层的功能，在系统的初始化阶段,网络拓扑发现功能自动找出网络中所有被管理资源的拓扑信息包括主机、网络设备、应用程序、服务器、数据库，所述拓扑信息将被存入专家库中，所述专家库的功能包括有自修复、自配置和自优化三类自主元素的数据汇总、分析和计算,并进行故障关联性分析，所述功能运用人工智能的方法实现混合式自主计算参考架构顶层中的统筹管理器的功能；

被管理资源主机上有完整的本地自主元素，所述本地自主元素使主机能在与中央采集控制系统的联系切断的情况下,根据本地策略做到自我管理；

有些被管理资源主机上的自主元素则不完整，所述不完整的自主元素没有分析部分,计划部分以及知识库部分,所述不完整的自主元素对应的主机不能做到自我管理，只为中央采集控制系统的监视部分提供子级监视，为中央采集控制系统的执行部分提供子级执行。

本发明还揭示了一种自主管理的虚拟网络系统，所述系统包括：

自主管理的硬件交付点装置；

自主管理的软件化服务装置；

自主管理的逻辑交付点装置，多路复用软件化服务器中的资源利用自主管理实现与软件化服务器之间进行推与拉的资源调度；

自主管理的业务交付平台装置，包括部署自动化、应用生命周期管理、和业务服务、订阅服务，业务交付平台装置利用自主管理实现与多个逻辑交付点服务器之间的操作有关资源的竞争，并利用自主管理实现与多个用户代理之间的操作请求有关资源的竞争；

自主管理的用户代理装置，包括系统管理员、业务运营人员、企业业务用户、企业项目管理办公室，所述用户代理具备智能的自主管理能力和图形界面；

以上各装置都有自主管理的层次，类似经典的自主计算参考架构层次，但从三层扩充到n层。

本发明还揭示了一种自主管理的虚拟网络系统的实现方法，所述实现方法包括：

基础自主管理实现方法；

虚拟网络实现方法；

自主管理虚拟网络特有的实现方法：包括会话协议、逻辑交付点服务、业务交付平台和集群拓扑。

根据本发明的自主管理的虚拟网络系统的实现方法的一实施例，所述会话协议包括：

虚拟网络因会话协议而能完成业务规划／设计环境完整性和服务质量保证，会话协议是有状态的，在点对点的通讯中能处理故障后的恢复、能利用Proxy/Gateway跨虚拟网络集群、并能封装、传输其它虚拟网络协议的荷载，

以一个会话代表一个企业应用，子会话代表应用里的多个服务，会话包的头里含有用户身份、穿越各代理的传输历史纪录，会话的指令同步检查点，

所述其它虚拟网络协议的荷载里，如果有资源状态的改变，则导致会话协议重新发送协议指令，传达资源状态的改变事实，如果会话协议为会话初始协议，将会重新发送邀请指令，

所述其它虚拟网络协议的荷载内容为：

若协议是介于用户代理和交付平台之间，用户请求首先产生接入会话，主要荷载为用户的请求及最后回应；

若协议是介于交付平台和逻辑交付点服务器之间，接入请求被验证通过后产生服务会话，主要荷载为被竞争、选取、隔离的逻辑资源；

若协议是介于逻辑交付点服务器和软件化服务器之间，在服务会话中，逻辑交付点与用户请求的业务绑定，当业务完成后不再绑定,此时服务会话也结束，主要荷载为已被软件化服务器融合的物理资源，成为逻辑资源；进行推和拉调度的荷载；

若协议是介于物理交付点和软件化服务器之间，主要荷载为将被融合的物理资源、预定义的状态改变和通知。

根据本发明的自主管理的虚拟网络系统的实现方法的一实施例，所述逻辑交付点服务器为：

所述逻辑交付点服务器包含多个逻辑交付点，所述每个逻辑交付点有三种不同的供应方案：

除了共享空间的特性，分时的逻辑交付点还支持虚拟服务器，而该虚拟服务器超额订阅物理的主机服务器，每个虚拟服务器相对于其他虚拟服务器，彼此之间具有不同的硬件规范，物理的主机服务器对于供应实例来说是不可见的；

除了虚拟服务器的硬件规范被随需提供以外，该虚拟服务器的操作系统也被随需供应在每个虚拟服务器上；

除了虚拟服务器的操作系统被随需提供以外，应用程序服务器被随需供应在每个被超额订阅的操作系统上。

根据本发明的自主管理的虚拟网络系统的实现方法的一实施例，所述逻辑交付点的实现步骤如下：

逻辑交付点面向业务交付平台，在处理竞争时，多路复用虚拟资源融合网络中的资源，根据虚拟有限状态机执行器方法和虚拟有限状态机规则库，解决多个业务逻辑交付点之间的资源竞争问题，若是操作请求竞争，则比较不同业务操作请求，在服务质量下得出竞争结果，若是操作竞争，则比较软件化服务器可用的资源、和物理交付点服务器里的各业务逻辑交付点需求，在服务质量下得出竞争结果；

逻辑交付点面向软件化服务器，进行软件化服务器和逻辑交付点服务器之间的推或拉调度，若是推调度，则不管物理交付点的能力而承诺资源的变化要求，支持并行化的资源供应，若是拉调度，则只有当物理的交付点容量准备好时才承诺资源的变化要求，支持并行化的资源供应。

根据本发明的自主管理的虚拟网络系统的实现方法的一实施例，所述业务交付平台接收来自不同用户的请求，如果是网管人员的硬件资源操作请求，则按照简单服务质量规则得出竞争结果，如果是企业业务人员，则进入业务生命周期管理，如果是业务运营人员则进入部署自动化，如果是项目管理经理，则进入订阅服务，由业务服务器的MAPE引擎做多部门、多业务的汇聚，供应业务环境，使项目管理经理做业务设计，如果是与逻辑交付点服务器的交流，则按照MAPE引擎计算的结果向逻辑交付点服务器下达指令，而另一方面，也接收逻辑交付点服务器逻辑资源不足的通知，转告MAPE引擎；

业务服务器的MAPE组件是全局的，而逻辑交付点服务器的MAPE组件则是服务器当地的，业务服务器的MAPE引擎的规则库除了考虑逻辑交付点服务器之间资源的竞争，还考虑从用户来的业务需求；

业务服务器面向项目运营用户时，进行业务生命周期管理，业务项目服务器处理配置、激活、部署、卸载、业务保障、业务调度和FCAPS管理；

业务服务器面向逻辑交付点时，逻辑交付点与业务项目是一一对应，以便程序管理办公用户订阅虚拟资源，进而订阅分布式物理资源，业务服务器供应业务环境并提供给项目管理经理业务设计。

根据本发明的自主管理的虚拟网络系统的实现方法的一实施例，所述虚拟网络的集群拓扑划分多个主机在不同集群里，集群中从节点容许有限失效，主-从群均为同构，集群需支持负载均衡，物理资源首先可以分割成许多物理交付点，每个物理交付点可以有多个集群，而逻辑交付点也因不同用户的设计而可以有多个，逻辑交付点提供随需操作系统的服务，在主机上迅速部署虚拟机，集群拓扑形成物理交付点时，将物理的集群分割成几个物理交付点或单个物理交付点，集群拓扑形成逻辑交付点时，若基于原有的单个物理集群，逻辑交付点仅限于单个集群，若基于多个集群则无上述限制。此二选择作为配置选项提供给用户，仅共享空间的逻辑交付点不会将物理服务器虚拟化，以确保计算的高质量和系统的性能，随需操作系统的逻辑交付点虚拟化物理服务器，以提供更多元化的开发/测试设备，此二选择作为配置选项提供给用户，逻辑交付点面向应用时，连接到业务交付平台的每个逻辑交付点均带有版本号，并使用业务交付平台的存储系统来实现存放和恢复，逻辑交付点面向软件化服务器时，使用拉调度来实现对后台资源的承诺，以避免网络流量爆发。

本发明对比现有技术有如下的有益效果：本发明的方案是在多循环自主管理、抢占性接触点、硬件资源软件化的发明之上，在分布式网络领域的业务交付虚拟网络以及应用保障系统和方法，并融合以上领域的发明，提供业务交付的虚拟网络的管理。

附图说明

图1是IBM的自主系统架构Autonomic Computing Reference Architecture（ACRA）的结构框图；

图2A是经典的自主元素模型的结构框图;

图2B、2C是外循环（经典）与内循环（非经典）的结构框图;

图3是“交换机发生故障”的诊断流程框图;

图4A是由事件来驱动的诊断流程方框图;

图4B是将各类事件映射到一个自主管理者中的情形以及存在于分析和规划两部分间额外的循环;

图5是复杂事件处理步骤的流程图；

图6是一个智能的复杂事件处理方法的流程图；

图7是混合式ACRA自主系统架构的结构框图;

图8是虚拟的和物理的自主管理的结构框图;

图9是一个智能的Ring0（环0）传感器和效应器系统的结构框图；

图10是一个智能的Ring0传感器和效应器实现方法的流程图；

图11A、11B是一个软件化服务系统的结构框图；

图12是一个软件化服务器的流程图；

图13是一个具有交付服务的虚拟网络企业架构框图；

图14是虚拟网络系统总体工作场景架构框图；

图15是虚拟网络系统自动化方法的流程图；

图16显示虚拟网络业务交付服务方法的流程图；

图17是网络应用保障系统及其子系统功能的分层关系图;

图18是虚拟网络系统的性能服务框架和监视器的结合架构图；

图19是网络应用保障系统的结构框图;

图20是子级Monitor（监视器）作CPU利用率超常判定和子级Execute（执行器）发出警告的流程图;

图21中央采集控制系统中自主管理者处理被管理资源VM n的CPU利用率超常警告后的流程图；

图22是一个自主虚拟网络的架构框图；

图23是用于自主虚拟网络的会话初始协议（SIP，session initiation protocol）的流程图；

图24是逻辑交付点（POD，Point of Delivery）服务器的流程图；

图25显示业务交付平台与用户互动的流程图。

图26是集群环境下POD的形成的流程图。

具体实施方式

下面结合附图和实施例对本发明作进一步的描述。

经典与非经典的自主元素模型

图2A所示是一个经典的自主元素模型。根据Kephart的描述,自主元素(autonomic element)是自主计算系统的基本构造块,它由一个自主管理者(autonomicmanager)和一到多个被管元素(managed element)组成。自主管理者代替了那些原本需要人工进行的管理工作,包括状态觉察和系统配置(configuration)、修复(healing)、优化(optimization)和保护(protection)等。自主管理者通过一个“监视(monitor)-分析(analyze)-规划(plan)-执行(execute)”控制循环(control loop)来实现这种管理任务。处理这四个控制循环的软件组件统称为MAPE组件。有关细节请参见根据Kephart的TheVision ofAutonomic Computing一文。

图2B和2C对比了一个自主元素模型经典的外循环和非经典的内循环。首先，自主管理者是上述4个循环过程的统称，仅为自主管理元素的一部分，不包括知识库和被管元素的接触点（传感器+效应器）。其次，一个经典的自主元素有所谓“外循环”，如图2B所示。该外循环包括传感器→分析器→规划（计划）→执行→效应器→传感器，可以有多次，这是IBM的自主管理早已有的。但本发明即将要揭示的是自主管理者的多次内循环，在本发明中称之为“多循环自主管理者”，意即循环是在相邻的两个MAPE组件之间，监视分析；分析

规划；和规划

执行，且可以有多次。图2C的自主元素仅显示分析

规划的内循环。但本发明的系统和方法也适用于监视分析和规划

执行的多次内循环。内循环的必要性将在图3，图4A，图4B，和图5解释。

由事件来驱动的诊断流程

目前大多数网络系统的故障诊断工作是由IT专业人员根据标准操作手册按部就班进行的。图3是一个排查发现交换机发生故障的操作过程:

步骤301：发现症状—不能ping（连通）某一个服务器。

步骤302A与302B：记录与该故障有关的信息，如服务器号，发生时间等。开始启动初步诊断过程。

步骤303：收集可能与该故障有关联的其它症状。

如果仅有该服务器不能被ping，那么有可能是该服务器在维护中，也有可能是该服务器发生故障。

如果在短时间间隔内有多个（超过100个）服务器不能被ping，那么有可能是交换机在维护中，也有可能是交换机发生故障。

步骤304：开始启动确诊过程。故障原因总共有四种可能:

假设是服务器在维护中，则需要检查ping失败是否是孤立的症状；需要检查系统Log文件有无“关机”记录；需要询问网络管理人员是否在进行维护工作。

假设是服务器发生故障，则需要检查ping失败是否是孤立的症状；需要检查系统Log文件有无“失败”记录。

假设是交换机在维护中，则需要检查是否有大面积的ping失败；需要检查系统Log文件有无“关机”记录；需要询问网络管理人员是否在进行维护工作。

假设是交换机发生故障，则需要检查是否有大面积的ping失败；需要检查系统Log文件有无“失败”记录。

步骤305A与305B：如果交换机Log文件有一个“失败”记录，并且存在大面积的ping失败，那么没有必要作进一步深入诊断，可以确诊是交换机发生故障。

步骤306A与306B：交换机发生故障的解决方法一般用另一台交换机来替换。

步骤307A与307B：再次ping原来不能被ping的服务器。如果能ping这些服务器了，说明上述“交换机发生故障”的诊断是正确的。

经过对许多故障诊断操作过程实例的观察，我们发现它们都符合一定的规律。它们都有“产生假设→进行调查→发现结果→得出结论”这样一个过程。这个过程早已被人们认知而被称为“科学方法”(scientific method)。有很多时候,单独一次调查所发现的结果往往不足以得出最后结论,这样的话上述产生假设→进行调查→发现结果的过程就需要循环往复进行多次,直至得出最后结论。正因为故障诊断操作过程有这样的规律性,我们可以用计算机来代替IT专业人员进行某些重复性的劳动,以协助IT专业人员进行故障诊断。

值得注意的是,上述网络系统故障诊断的对象可以存在于实体网络环境中,也可以存在于虚拟网络环境中。在虚拟网络环境中,上述服务器和交换机可以是虚拟的,也就是它们可以是运行在Hypervisor上的软件。它们可以由下面的Hypervisor来操控,包括启动和停机。因此,从原理上讲,我们不仅可以用计算机来代替IT专业人员进行上述步骤301到步骤305的故障诊断工作,而且可以用计算机来进行上述步骤306到步骤307的故障恢复工作。

我们可以运用自主系统架构来设计一个虚拟网络的自主管理系统,由计算机来进行上述的故障诊断和恢复工作。该虚拟网络的自主管理系统应具有以下的功能特点：

(i)自配置：其能够适应网络系统中的变化。这样的变化可包括新网络设备的部署或者除去已有的设备;新软件的部署或者卸去已有的软件。动态的适配帮助确保计算设备/软件的连续运转。

(ii)自优化：能够自动地监视和协调资源以满足终端用户或者企业需求，从而提供高性能的服务；

(iii)自修复：能够检测系统故障和启动预定的改正动作而不中断系统的其余部分。能够将因此，系统将变得更有复原力。

交换机发生故障的诊断流程

自主管理者的实现方法一般有两种,一类是用轮询(polling)的方法,另一类是事件驱动(event-driven)的方法。由于事件驱动方法有实时性强,系统延迟短,和处理事件量大等优点,我们在设计虚拟的自主管理者时主要采用该方法。

我们仍用上述的交换机故障诊断和恢复的操作过程作为实例,来说明如何来有系统地设计虚拟的自主管理者尤其是其策略部分的方法。

我们先将上述的排查发现交换机发生故障的操作过程进行梳理,用一个流程图来表示各步骤的故障诊断工作,请参见图3。当系统第一次发现症状“不能ping某一个服务器”时,其第一次假设包括“该故障可能与交换机有关”。在进行第一次调查“收集可能与该故障有关联的其它症状”完成后,其发现结果即第二次发现症状“短时间间隔内不能ping多个（超过100个）服务器”可以确认第一次假设,但不足以得出最后结论,即该故障是因为“交换机在维护中”还是“交换机发生故障”。因此系统第二次假设包括“交换机发生故障”。在进行第二次调查后,其发现结果即第三次发现症状包括“有大面积的ping失败”及“系统Log文件有‘失败’记录”,这时系统可以得出最后结论“是交换机发生故障”。

我们可以清楚地观察到，上述的交换机故障诊断是循环往复进行了三次“产生假设→进行调查→发现结果→得出结论”这样一个过程,才得出了最后结论。实际上,当系统第一次发现症状“不能ping某一个服务器”时,其最后结论的可能性总共有四种:服务器在维护中;服务器发生故障;交换机在维护中;交换机发生故障。出于对简洁性的考虑,图3仅仅描述了“交换机发生故障”的诊断流程而略去了得到另外三种最后结论的流程。

当然,如果系统在第一次发现症状“不能ping某一个服务器时”后,能够进行调查并发现所有所需要的症状即:“短时间间隔内不能ping多个（超过100个）服务器”;“有大面积的ping失败”及“系统Log文件有‘失败’记录”,就可以不进行多次循环而立即得出最后结论:“交换机发生故障”。在现实中,这些所需要的症状往往存在于网络系统中不同的地点,不同的层面,甚至是不同的时间段内。要一次性地收集到所有需要的症状往往是不经济的,有时(特别是多个症状间存在前后因果关系的情况)是很困难的。当然,当发生故障的原因比较简单时,即发生的症状和原因是1-1对应关系时,系统能立刻得出了最后结论,而不必经过“产生假设→进行调查→发现结果→得出结论”这样一次过程。这种情况下文还会涉及。

本发明的一个重要方法在于:我们将图4A中的每一步即每个方块框中的内容,看成是一个事件(event)。而连接各个方块框的箭头,则可以看成是一个活动(activity)。在图4A中,有十二个方方块框即十二个事件。这事件可归纳为五类:发现事件,假设事件,调查事件,结论事件和恢复事件。而图4A中的箭头(虽然未具体表示出来),应该代表了一次过程中的五种活动,即:产生假设,进行调查,发现结果,得出结论,进行修理。如果我们把图4A中的各个方块框归纳为箭头来表示,再把图4A中的各个箭头归纳为方块框,则可以我们将图4A转换成一个由事件来驱动的流程方框图,请参见图4B。

事件映射与额外循环

目前,每个方块框中活动(activity)是由IT专业人员根据标准操作手册按部就班进行的,而我们的目标就是由计算机来进行这部份的判断工作。因此,我们将图4B中的事件映射到一个自主管理者中,请参见图4B。这样,该自主管理者的分析(analyze)和规划(plan)部份都可以用一组规则来表示。

分析(analyze)部分的规则是:

状态0时:if发现事件(不能ping某一个服务器)

then{output假设事件(该故障可能与服务器有关);

output假设事件(该故障可能与交换机有关);

状态增加1}

状态1时:if发现事件(不能ping服务器的计数>100)

then{output假设事件(交换机在维护中);

output假设事件(交换机发生故障);

状态增加1}

状态2时:if发现事件(不能ping服务器的ID不同,即大面积ping失败)and发现事件(系统Log文件有“失败”记录)

then{output结论事件(交换机发生故障);

状态归为0}

分析(analyze)部分的规则是:

状态0时:if假设事件(该故障可能与交换机有关)

then{output调查事件(收集可能与该故障有关联的其它症状);

状态增加1}

状态1时:if假设事件(交换机发生故障)

then{output调查事件(大面积的ping失败);

output调查事件(系统Log文件有“失败”记录);

状态增加1}

状态2时:if结论事件(交换机发生故障)

then{output恢复事件(替换交换机);

状态归为0}

请参见图4B。该自主管理者的监视(monitor)和执行(execute)部份规则相对简单,不必含有状态。但输入或输出需根据具体情况而定。

监视(monitor)部分的规则是:

if exist Warning(ping一个服务器失败)

then{output发现事件(不能ping某一个服务器)}

if count Warning(ping一个服务器失败)>100个,间隔为30秒

then{output发现事件(不能ping服务器的计数>100)

}

执行(execute)部份的规则是:

if exist恢复事件(替换交换机)

then{创建替代交换机;

迁移;

删除故障交换机}

复杂事件处理步骤

上面这些规则可以由复杂事件处理（Complex Event Processing,即CEP）技术来实现，其步骤参见图5。具体地讲,可以是Esper引擎的instance（实例）或者其它CEP引擎的instance。由于CEP技术目前尚未形成统一格式的标准描述语言,而各不同引擎的描述语言差别又很大,我们不在这里给出具体的语言描述。因为本发明并不锁定于某一种CEP语言,因此我们在这里尽量运用通用的描述语言。

假设我们运用Esper作为我们的CEP引擎,对于上面一个故障诊断和恢复的操作过程实例,我们就可以用四个Esper引擎的instance来实现自主管理者的四部份规则。而对于一系列的故障诊断和恢复操作过程实例,我们用一系列的自主管理者来实现故障诊断和恢复操作过程的自动化(有多少个实例即有多少个自主管理者)。自主管理者四个部份的每一个部份包括一个Esper引擎的instance。而每个instance中可以包含有多条规则(rule)。

根据David Luckham的The Power of Events一书,上述的每个instance就是一个事件处理代理Event Processing Agent(EPA)。而自主管理者就是由四个EPA连接而成。Luckham把相互连接而构成的EPA网络,称作事件处理网络Event Processing Network(EPN)。虽然EPA的概念已提出多年(The Power of Events一书出版于2005年),但运用EPA的实例目前还不多,大多数应用仍将CEP引擎作为规则引擎单独使用以集中处理含大批量的事件的多路事件流(event stream)。而利用CEP引擎的instance可以随时创建随时使用的特性,将CEP技术运用于虚拟网络的动态管理,则是我们所首创。

CEP引擎的每个instance是可以动态地创建和删除的,我们可以将一系列的故障诊断和恢复操作过程变成一系列的规则集合,放在数据库中。在需要的时候从库中取出一套,赋给新创建的CEP引擎的四个instance,然后这四个instance就可以分别加入到自主管理者的监视(monitor),分析(analyze),规划(plan)和执行(execute)四个部份中去。创建一个CEP引擎instance的实例如图5所示:

步骤501：开始配置引擎,

Configuration config=new Configuration();

步骤502：定义输入事件类型例如Monitor,

config.addEventType(“Monitor”,Monitor.class);

步骤503：获得引擎的instance,

epService=EPServiceProviderManager.getDefaultProvider(config);

步骤504：如果该引擎的instance已被引用过则需要初始化,

epService.initialize();

步骤505：把从数据库中取出的规则rule(String类型)赋给引擎的instance,EPStatement statement=null;

statement=epService.getEPAdministrator().createEPL(rule);

步骤506：该引擎的instance连接到侦听器MonitorListener(),

statement.addListener(new MonitorListener());

输入507：由传感器收集到的事件发生了；

步骤508：决定事件是否使用结束。若是，进行步骤509；若否，进行步骤510；

步骤509：该引擎的instance在使用结束后可以删除,以便释放其资源,epService.destroy();

步骤510：智能的多循环复杂事件处理。

由于EPA的输入和输出均为事件流,而上述的步骤又不涉及到具体的硬件设施,所以这些EPA即自主管理者可以被动态地替换而不影响任何一个被管元素。由此,自主管理者的创建和删除均可以在虚拟网络仍在工作的状态下在线进行。而自主管理者本身则可以是虚拟的。这一点是本发明与众不同的地方。

由于EPA的规则体现了故障诊断和恢复的操作过程，因而由EPA来构建的自主管理者和以往的自主系统相比,在结构上有所不同。主要的不同点是在分析(analyze)和规划(plan)这两部分中间增加了至少一个额外的循环。请参见图2A－2C中椭圆型部分。这种额外的循环在经典的自主元素模型中是不存在的。因此,该自主管理者是非经典的,是对经典的自主元素模型中的自主管理者的一种扩展。

正是由于有了这样一个额外的循环(可以循环多次),使得EPA构成的自主管理者有了比传统的自主系统更强的病因调查(root cause analysis)能力。自主管理者可以自动地循环往复地模拟“产生假设→进行调查→发现结果→得出结论”这样一个原来由IT专业人员人工进行的调查过程。相应地,在分析(analyze)和规划(plan)这两部分的规则中应用了“状态”概念(相当于有限自动机)。“状态”则体现了当前自主管理者正处于哪一个循环状态。而“状态”的变化,是由各类事件来驱动的。

当然,在被管理的系统中,还会存在大量的(有时是绝大多数)原因比较简单的故障。该类故障的症状和原因是1-1对应关系。因而其故障诊断过程不必经过额外的循环,立刻能根据判定规则找到故障发生的原因。在这种情况下,由EPA来构建的自主管理者并不构成额外的循环,因此仍然遵从经典的自主元素模型。

智能的多循环复杂事件处理方法

图6显示了智能的多循环复杂事件处理方法。CEP本身并不一定是智能的，但EPA的设计可以将智能加入，并可从过去的经验学习。如前所述，自主计算的由来是模仿人的大脑的执行功能，而大脑执行时负责记忆的神经元扮演重要角色。这种记忆分为三种：插曲（episodic）记忆，语意（semantic）记忆，和过程（procedural）记忆。插曲，是一组事件有意义的组合，以下称为“事件列（a sequence ofevents）”。事件列可以只包含单一事件，例如“CPU使用率已达95%”。多个事件的事件列的最佳例子就是产品的故障单据，通常由用户好几次的询问和客户服务人员的回复组成，每次的询问就是一个事件，全部有关该故障单据的多次事件组成一个“事件列”。事件列类似于短暂记忆，经常改变，但累积的经验则成为长期记忆，通常可以用“规则库”来模仿。语意记忆则是一些相对不变的事实，例如“微软公开发布的Windows7的前一版是Windows Vista”这样一个事实，通常保存在“知识库”里。能从经验学习的智能CEP方法可以参见Dan Gabriel Tecuci 2009所发表的论文“An Episodic Based Approach toComplex Event Processing”。为自主管理的分析者（Analyzer）提供了事件列（即插曲）规则的保存和搜索方法。不过，该方法并不能直接用于本发明的多循环自主管理上，以下步骤则是分解了其方法中的“同步”概念，应用在多循环的自主管理场合：

步骤601，智能的多循环复杂事件处理初始化；

步骤602，判断是否为监视器EPA。若是，进行步骤603，否则进行步骤606；

步骤603，根据语义知识库，把事件数据翻译成规则，记录刺激（stimuli）。进行步骤604；

步骤604，结合多个规则成为有意义的事件列（event sequence）。进行步骤605；

步骤605，将事件列存入规则库。进行步骤606；

步骤606，判断是否为分析器EPA。若是，进行步骤607，否则进行步骤612；

步骤607，从规则库搜寻符合当前刺激的事件列。进行步骤608；

步骤608，判断是否成功搜到事件列。若是，进行步骤611，否则进行步骤609；

步骤609，判断是否往复循环。若是，重新发现并进行步骤603，否则进行步骤610；

步骤610，调节参数。进行步骤611；

步骤611，利用分数匹配到MAX_Hypo个最相似的事件列，称为假设。进行步骤612；

步骤612，判断是否为计划器EPA。若是，进行步骤613，否则进行步骤620；

步骤613，把状态、行动、目标加入语义知识库。进行步骤614；

步骤614，从观察到的行动形成元状态。进行步骤615；

步骤615，识别目标、目标参数、实例化的目标。进行步骤616；

步骤616，从规则库搜寻符合目标和元状态的假设。进行步骤617；

步骤617，判断是否往复循环。若是，再次调查并进行步骤607，否则进行步骤618；

步骤618，把不能完成任务的假设存入规则库。这样，经验才可以累积，从失败中学习。进行步骤619；

步骤619，只有最相似的假设才被改编（Adapted），称为修复计划。进行步骤620；

步骤620，判断是否为执行器EPA。若是，进行步骤621，否则进行步骤629；

步骤621，形成策略以备选择。进行步骤622；

步骤622，从方案规则库，搜寻符合策略的修复计划。进行步骤623；

步骤623，判断是否成功搜到修复计划。若是，进行步骤626，否则进行步骤624；

步骤624，判断是否往复循环。若是，再次计划并进行步骤613，否则进行步骤625；

步骤625，调节参数。进行步骤626；

步骤626，利用分数匹配到最相似的修复计划，称为最佳解决方案。进行步骤627；

步骤627，最佳解决方案交给效应器执行。进行步骤628；

步骤628，正常返回；

步骤629，错误返回。

混合式ACRA

请参见图7。上述经典的和非经典的两类自主元素可以同时在ACRA自主系统架构中,主要是在中间层。由此,混合式ACRA自主系统架构的底层包含有虚拟的和非虚拟(物理)的网络设备,它们作为被管资源存在ACRA自主系统架构中,有的本身就含有自我管理的属性。中间层则是大量的由EPA来构建自主管理者的自主元素。每个元素代表一项原本由IT人工进行的管理工作,例如某种故障的诊断。这些自主元素作为资源管理器存在于ACRA自主系统架构中,它们实现自配置,自优化和自修复中的某一类任务。需要强调的是,和经典的ACRA自主系统相比,我们的中间层设计有三个特点:1)自主元素的自主管理者由EPA即Event Processing Agent实现;2)有些自主管理者的分析(analyze)和规划(plan)两部分含有额外的循环;3)由EPA来构建自主管理者的数量多而且是动态构建的。这些特点使得我们的自主元素本身也可以是虚拟的。

混合式ACRA自主系统架构的顶层包含有协调各种中间层资源管理器的统筹管理器。统筹管理器主要全系统范围的自主管理,例如,将长期不用的中间层自主元素淘汰删除。当现有的自主元素不能完成管理任务时,向IT专业人员人工发出请求以便进行人工干预。

因此,本发明的目标之一在于构建基于ACRA自主系统架构的可以对虚拟网络设备有自配置,自修复和自优化功能的自主管理系统。

虚拟环境下的自主管理

虽然上述的多循环CEP自主管理系统和方法，可以应用用于任何自主计算的情况，本发明内容的另一重点却是在于如何设计和构造自主管理者，使其运行在虚拟的环境下，以管理虚拟网络中的所有资源,包括虚拟服务器(VM)和虚拟交换机(VSwitch)。请参见图8。其中,NIC是物理网卡,VNIC是虚拟网卡。在还没有管理资源之前，自主管理者有必要完成其本身代码的动态部署，可以利用ACRA的三层结构和应用虚拟化来进行。

统筹管理器Orchestrating Manager首先在离线状态时将资源管理器ResourcesManagers所需要的应用软件，也就是各种智能的EPA，虚拟化成为文档，以FTP（filetransfer protocol）方式传到资源管理器。其次，资源管理器在离线状态部署了该虚拟化后的应用，进而产生OS（操作系统）镜像。这些镜像和已安装了Hypervisor（或称为Virtual Machine Monitor,简称VMM）的被管理元素（Managed Elements）做镜像同步，因此所有的EPA可以不断被更新。在有的情况，EPA是用LISP逻辑语言编写时，数据和程序一体，更新/部署频繁（而非仅仅更新数据库里的数据），这时，应用虚拟化技术就更重要。如果被管理元素没有安装Hypervisor（也就是OS没有被虚拟化），则可以把虚拟化后的应用文档经串流技术直接部署在被管理元素的主机OS上。有关应用经过拆分和重组被虚拟化，以及OS镜像利用差分来同步的细节，请参阅汤传斌的中国专利申请201010183844.6“客户端虚拟化架构”。简言之，应用虚拟化是在离线时将应用软件拆分成几个模块，连同安装信息压缩后保存为文档，在部署时使用外网串流（internet streaming），或内网的文档拷贝（intranet file copying）到在线机器的OS上（如果OS没有被虚拟化），或被虚拟化的OS镜像上；解压后，再利用安装信息重新组合。如果OS被虚拟化，则还可以定期比较ACRA资源管理器（有如Server）的镜像和被管理对象（有如Client）的镜像差异，将两边镜像同步，称为差分同步。把上述专利的应用软件拆分/重组和OS镜像差分同步技术，应用到本发明的自主管理ACRA三层结构，并非熟悉这领域的人可以想见的。

事实上，自主管理有三种虚拟环境，图8所示仅为第一种：

（1）应用虚拟化。自主管理借用应用虚拟化达成本身代码的动态部署。如上所述，自主管理本身为一个应用软件，它的动态部署和动态消除可以藉着应用虚拟化以及OS镜像同步来实现。

（2）OS虚拟化。自主管理协助OS虚拟化的主机性能优化和保障。被管理的自主元素包括传感器和效应器。传感器收集性能数据，经由自主管理者的分析和计划，可以提升所运行主机的性能，而效应器更可使用Hypervisor Ring0的抢占权限防范问题于未然。更多详情请参考图9。

（3）硬件虚拟化。自主管理协助硬件虚拟化。硬件资源在被规划或运行时，可以透过自主管理者的分析和计划，加上状态机的能力计算，达到统筹、融合供应资源的目的。资源管理器既可以管理虚拟资源(图8中以虚双箭线表示),包括虚拟服务器,虚拟交换机,虚拟网卡;也可以管理物理资源(图8中以实双箭线表示),例如物理交换机。更多详情请参考图11。

智能的Ring0传感器和效应器系统

图9显示一个智能的Ring0（环0）传感器和效应器系统。在一个计算机里，有应用级别的软件和内核级别的软件（后者包括操作系统OS和虚拟机监视器VMM）。所有的应用和内核系统/子系统最终都要扇入（Fan-in）到CPU上。一般的业界监视器产品，无非也是这两个级别的软件，与被监视的软件竞争CPU cycle。也就是说，监视器和被监视软件属于相同的环权限，因而无法事先预测事件的发生。这些产品只能用所谓“检察点（check-points）”的方法做事后告警（例如知道某些被监视进程已然失败），大大丧失了监视器原本就该有的实时预警效果，无法实现真正的QoS（Quality ofService）质量保证。

本发明（抢占性接触点），最重要的概念在于传感器和效应器运行在操作系统内核，具有Ring0权限，比被管理的软件进程的权限级别高，因而在侦测到被管理软件进程可能频临危险，可以实时、事先采取行动，例如改变被管理软件进程的时间片，停止其运行，或者，在有VMM的情况时，迁移该虚机到不繁忙的主机上运行。

图9中的方框91是传感器。它包含了在Ring0运行的具有监视功能的PMU硬件驱动911。能侦测到应用软件频临危险的关键在于传感器是一个硬件级别的性能侦测单位（Performance Monitoring Unit，或PMU，方框912），而不是利用OS里的性能指令来侦测。PMU仰赖控制寄存器913PMC（performance monitor control register）和数据寄存器914PMD（performance monitor data register）来实现性能侦测。

方框92是健康保障进程，运行进程p0。方框931和932分别是被管理的应用软件，运行进程p1和p2。这里要说明的是如果健康保障进程仰赖的是OS性能指令，则其运行权限和p1或p2没有不同，因此无法干涉p1或p2的运行。这一观点最容易用方框94效应器里的OS调度器941说明，因为调度器对p0、p1、p2这三个进程是平等对待的。

方框95说明当频临危险的应用软件p1或p2被912PMU侦测到以后，经由CPU发起中断，这时方框95，Interrupt Service Routine（ISR），可以中断OS调度器，然后按规定做调整。这些规定可以是一些简单的规则，例如“如果CPU使用率超过99%，终止p2运行”。

图9显示的是主机没有OS虚拟化的情况。对于主机有OS虚拟化的情况，可以参阅图18的说明。

智能的Ring0传感器和效应器实现方法

虽然上述智能的Ring0传感器和效应器系统概念很简单（即以抢占权限实现系统保障），但实现起来需要解决若干问题：（1）被监视的事件数超过PMU的计数器数目的问题；（2）使用何种OS调度器方法（algorithm）的问题；（3）有Hypervisor（VMM）时的处理问题；（4）规则库如何简单快速回应的问题；（5）如何在不同OS或硬件平台实现的问题。以下说明图10智能的Ring0传感器和效应器实现方法的步骤：

步骤1001：初始化--本流程图的逻辑均运行在OS或VMM内核；

步骤1002：判断是否为平台无关模块。若是，进行步骤1003。否则进行步骤1017；

步骤1003：判断是否为传感器。若是，进行步骤1004的进程级别监视或步骤1006的系统级别监视。否则进行步骤1008；

步骤1004：进程级别监视，进行步骤1005；

步骤1005：多路复用进程资源，使在被监视的事件数超过PMU计数器数量，仍然可以监视。进行步骤1020；

步骤1006：系统级别监视，进行步骤1007；

步骤1007：TLB丢失、PCI BUS延迟及流量、CPU停顿周期、内存访问延迟、设备访问延迟、缓存指令停顿，等等。进行步骤1020；

步骤1008：判断是否为效应器。若是，进行步骤1009。否则进行步骤1016；

步骤1009：使用成组(gang)调度器，有别于业界常用的CS（Credit Scheduler），CFS（Complete Fair Scheduler），RSDL（Rotating Staircase Deadline Scheduler），BVT（Borrowed Virtual Time Scheduler），和EDF（Earliest Deadline First）方法。进行步骤1010；

步骤1010：在Ring0中断，进入ISR。进行步骤1011；

步骤1011：进行程序性规则快速判断。进行步骤1012；

步骤1012：判断是否为虚拟化（意即使用Hypervisor）。若是，进行步骤1013。否则进行步骤1015；

步骤1013：系统经由UpCall将指令传到虚机，虚机经由Hypercall将状态返回。进行步骤1014；

步骤1014：按照规则（1）停止，重启，迁移虚机（2）停止分配时间片，直到高峰时间过去。进行步骤1020；

步骤1015：按照规则（1）停止，重启进程（2）停止分配时间片，直到高峰时间过去。进行步骤1020；

步骤1016：程序性规则库：接受由事件列规则库演化而来的规则更新。这些规则模仿人脑的程序性记忆（procedural memory）的无意识自主行动，存储于OS/VMM核心，以便快速回应。规则内容则是由经验的累积而成，有赖图6的智能多循环的复杂事件处理方法。接下来进行步骤1020；

步骤1017：判断是否为平台依赖模块。若是，进行步骤1018。否则进行步骤1021；

步骤1018：将PMU watchdog（看门狗）,ISR的PMU部分,以及PMU核心代码（这些组件统称为“性能监视器硬件的驱动软件”，或the software driver ofperformancemonitoring hardware）和OS内核代码分离。进行步骤1019；

步骤1019：将从OS分离的驱动移植到其它硬件平台。进行步骤1020；

步骤1020：正常返回；

步骤1021：错误返回。

软件化服务系统

图11显示一个软件化服务系统。物理资源的“软件化（software-defined）”，或称为“硬件虚拟化（hardware virtualization）”，或称为物理资源的“融合（convergence）”。该系统利用虚拟有限状态机模型（VFSM）描述和控制基础设施资源的能力（Capability），形成软件定义的资源对象，并利用软件定义的资源对象实现交付点POD（Point ofDelivery）资源的供应（Provisioning）。本图以物理交付点（Physical POD）创建虚拟机的能力为示例。所谓物理交付点，乃是在数据中心网络中经过定义和划分设备集合，所构成的资源供应物理单元，该单元可不依赖于其他设备而独立工作；最终形成POD资源服务单元。这是一项创新的思维，也就是说，资源供应的基本单元，不是一个物理机，一个虚机或一个虚拟交换机，而是他们之间的一个（有意义的）“集合”。

图11A是创建虚机的请求事件如何被拦截，经过VFSM执行器读取当前状态和查阅规则库，判断出当前资源无能力创建虚机，于是将当前状态和告警行动传给软件化服务器。图11B则是软件化服务器为了物理POD的供应要能创建虚机，将需要的新资源数据和参数更新当前状态，触发了VFSM执行器判断此一新状态可以引发物理POD新的进入（entry）服务，于是将此新的进入服务参数和服务数据送回物理POD，最终实现虚拟机的安装。

图中的自主管理的标志，表示过程是按照自主计算的ACRA架构进行。步骤如下：

步骤1101：“虚拟机数量从4变为5”的请求并未直接在物理POD实现，而是由物理POD的监视器发送变迁事件给软件化服务器；

步骤1102：软件化服务器的监视器收到后启动VFSM执行器；

步骤1103：VFSM执行器向规则库查阅变迁规则，得到的VFSM规则是：“若VM数量小于5，则判断为是且动作为通知；若VM数量大于或等于5，则判断为否且动作为告警。”；

步骤1104：VFSM执行器判断虚拟机VM的创建能力为“无”，于是变迁当前状态，执行告警动作；

步骤1105：软件化服务器获得当前状态；

步骤1106：软件化服务器为了实现物理POD的供应，决定安装新的VM（输入该VM的服务数据和服务参数）；

步骤1107：VFSM的当前状态从软件化服务器获得新的能力状态，设置状态为NEW；

步骤1108：新状态触发VFSM执行器，并将状态输入（数据和服务参数）VFSM执行器；

步骤1109：VFSM执行器向规则库查阅新服务，和参数，得到的规则是“VM能力为新；而且实现进入（Entry）服务（数据，参数）”；

步骤1110：VFSM执行器告诉服务模块启动NEW的进入服务（服务数据和服务参数）；

步骤1111：软件化服务器利用服务传输协议告诉物理POD的服务模块（服务数据和服务参数）；

步骤1112：物理POD安装VM。

软件化服务的实现方法

图12介绍了软件化服务器的逻辑。软件化服务器包含具有硬件资源属性和状态的管理信息库MIB（management information base），VFSM执行器，VFSM规则库，和VFSM监视器。物理POD和软件化服务器形成一个Client客户端/Server服务器架构。这里虽然只介绍软件化服务器的全局组件（global components），但按照自主管理ACRA的架构，物理POD（也就是客户端）也可以具有1-1对应的当地组件（localcomponents），例如物理POD也有MIB和/或VFSM执行器、规则库、监视器、进入（entry）状态/离开（exit）状态的服务等组件，此1-1对应如图10虚线两端所示。另一方面，软件化服务器也要面对逻辑POD。一个逻辑POD是用户业务项目所需计算、网络、存储逻辑资源的组合，按照用户所定规格而来，其中的资源具有共享空间和共享时间（所谓分时）的特性。

步骤如下：

步骤1201：软件化服务器是基于虚拟有限状态机（VFSM）对于内网和外网资源进行能力计算;VFSM可以用于系统设计时或运行时。进行步骤1202；

步骤1202：软件化服务器的初始化。进行步骤1203；

步骤1203：判断是否为VFSM数据库MIB。若是，进行步骤1204；否则进行步骤1214；

步骤1204：判断是否为硬件资源属性。若是，进行步骤1205或1207或1209；否则进行步骤1211；

步骤1205：计算资源增删读改。进行步骤1206；

步骤1206：CPU，PCI，板卡，中断，内存的增删读改。进行步骤1223；

步骤1207：网络资源增删读改。进行步骤1208；

步骤1208：软件断开，vLAN，数据平面，控制平面的增删读改。进行步骤1223；

步骤1209：存储资源增删读改。进行步骤1210；

步骤1210：LUN,磁盘，扇区，MDS，SAN，NAS的增删读改。进行步骤1223；

步骤1211：判断是否为硬件资源状态。若是，进行步骤1213；否则进行步骤1212；

步骤1212：错误返回；

步骤1213：建立硬件资源状态仓库。进行步骤1214；

步骤1214：增删读改路由器、交换机、服务器的状态。进行步骤1223；

步骤1215：判断是否为VFSM状态机执行器。若是，进行步骤1216或1217；否则进行步骤1219；

步骤1216：面向物理资源POD解决答下列问题：物理资源使用情况如何？根据流量数据，如何改变逻辑拓扑？何时激活哪一个交换机？需要多少服务器？如何挂接存储？进行步骤1218；

步骤1217：面向逻辑POD解决资源竞争问题和资源调度问题。进行步骤1218；

步骤1218：执行器根据满足资源状态、QoS、和VFSM规则所建立的“VFSM模型”方法计算能力（Capability）、执行事件。进行步骤1223；

步骤1219：判断是否为VFSM规则库。若是，进行步骤1220；否则进行步骤1221；

步骤1220：按照智能的多循环复杂事件处理方法，进行VFSM规则库的存储、调整、和搜索。进行步骤1223；

步骤1221：判断是否为VFSM能力监视器。若是，进行步骤1222；否则进行步骤1224；

步骤1222：智能的Ring0传感器和效应器监视VFSM能力，防止过载或超出能力。进行步骤1223；

步骤1223：正常返回；

步骤1224：错误返回。

具有交付服务的虚拟网络企业架构

图13显示了一个具有交付服务的虚拟网络企业架构。一般而言，电信界已经有TMN(Telecommunication Management Network),eTOM(Enhanced Telecom OperationMap),NGOSS(New Generation Operations Software and Support),TMF(TelecomManagement Forum)等针对电信网络提出来的标准，本实施例在此使用eTOM的标准。由图中可见，eTOＭ的原始概念已由“业务交付平台(Service Delivery Platform，SDP)”替代。原始的运营支撑和准备（Operations Support and Ready，OSR）概念成为离线业务交付，而原始的合约履行（Fulfillment）概念成为在线业务交付。业务交付是一个电信概念，但使用于企业网络，并能“自动化”，使用“生命周期管理”，则是本专利的创新。自动化表示这个系统的计算、网络、存储资源可以被融合、分配给多个业务项目平行操作。应用程序生命周期管理则是掌控了应用程序的注册、订阅、创建、设计、部署、卸载。注意：自动化与自主化并不相同，不同处在于自动化强调机房的资源管理的自动化（而非手动），但自主化却强调智能方法。

企业架构（enterprise archicture）是一个复杂的系统。本实施例所提及的eTOM概念可以参见“Enhanced Telecom Operations Map(eTOM)The business processframework”，ITU-T Recommendation M.3050.1。图13中的方框均与虚拟网络有关，但因企业项目本身常与该企业的专门业务相关，而且第三方资源也无标准，所以不列入自动化的范畴。因此，这里仅说明以下方框：

方框131是企业环境设计和规划。这部分修改了eTOM里有关业务的策略/承诺(strategy/Commit)和基础设施的生命周期管理(Infrastructure Lifecycle Management)，着重在业务环境下与业务项目管理经理PMO（Program Management Officer）互动的业务设计服务和与业务用户互动的业务订阅服务。

方框132是企业环境交付管理（或离线准备）。这部分修改了eTOM里的产品生命周期管理（Product Lifecycle Management,或PLM）和业务运营准备和支撑（ServiceOperation Support and Readiness,OS&R），着重在业务的离线逻辑环境。

方框133是企业环境在线交付和运营保障。这部分修改了eTOM里的业务合约履行（Service Fulfillment）和业务保障（Service Assurance），着重在业务的在线交付环境，以及应用保障系统的业务管理部分。

方框134是IT资源设计和规划。这部分修改了eTOM里有关资源的策略/承诺和基础设施的生命周期管理，着重在PMO/系统管理员的虚拟和物理资源设计服务。

方框135是IT资源交付管理（或离线准备）。这部分修改了eTOM里的产品生命周期管理（Product Lifecle Management,PLM）和资源运营准备和支撑（Resource OperationSupport and Readiness,OS&R），着重在未分配的虚拟资源和物理资源。

方框136IT资源在线交付和运营保障。这部分修改了eTOM里的资源合约履行（Resource Fulfillment）和资源保障（Resource Assurance），着重在已分配虚拟和物理资源的在线交付环境，以及应用保障系统的资源管理部分。

虚拟网络系统总体工作场景

图14显示虚拟网络系统总体工作场景。本图进一步阐述图13的概念，园框141是属于企业业务计划的部分，方框142才是虚拟网络概念的主体。分述如下：

园框141表示企业业务交付服务网站，包括企业业务核心服务，企业设计服务，企业订阅服务，和企业交付调度服务。

方框142虚拟网络主体概念，包括：

（1）园框1421业务逻辑环境服务网络，业务交付调度支持自动或人工的离线-在线环境切换，因此支持多版本企业环境的调度。包括离线业务逻辑环境，和在线业务逻辑环境。

（2）园框1422业务逻辑环境存储网络，包含数个业务实例的环境。

（3）园框1423业务逻辑环境资源网络，独占式资源订阅交付。包含数个业务实例的环境。

（4）园框1424虚拟资源网络，虚拟资源汇聚不同位置、配置的物理资源，实现物理资源类型、部署无关化的资源融合。包括未分配虚拟资源和已分配虚拟资源。已分配虚拟资源具有虚拟资源的独占和共享支持。

（5）园框1425为企业业务划分的数据中心和物理资源服务网络，支持订阅交付，同时支持按空间分享和按时间分享物理资源，包括许多未分配和已分配的物理资源，例如网络、存储、计算资源。

虚拟网络系统自动化的方法

图15显示虚拟网络系统自动化方法的流程图。自动化包含三个部分：首先是用户业务调度供应（调用虚拟资源调度供应）。其次是虚拟资源调度供应（调用虚拟资源调度供应）。再其次是物理资源调度供应（调用图11的软件化服务系统）。这里也描述了全面的业务自动化，包括应用的自动激活和配属管理，自动QoS管理和自动映射资源到物理网络并立即执行。步骤如下：

步骤1501，自动化的初始化。进行步骤1502；

步骤1502，判断是否为用户业务调度供应。若是，进行步骤1503；否则进行步骤1516；

步骤1503，业务资源需求设计服务。进行步骤1504或1505或1506；

步骤1504，业务计算资源需求例程。进行步骤1507；

步骤1505，业务存储资源需求例程。进行步骤1507；

步骤1506，业务网络资源需求例程。进行步骤1507；

步骤1507，系统资源分析服务。进行步骤1508；

步骤1508，虚拟资源预约和部署服务。进行步骤1509；

步骤1509，虚拟资源调度供应。进行步骤1510；

步骤1510，判断虚拟资源能力是否不足。若足，进行步骤1511；若不足，进行步骤1514；

步骤1511，返回资源预约和部署服务。进行步骤1512；

步骤1512，返回系统资源分析服务。进行步骤1513；

步骤1513，业务交付服务（包括业务接入服务，详见图16的流程）。进行步骤1524；

步骤1514，虚拟资源QoS和错误服务。进行步骤1515；

步骤1515，业务QoS和错误服务。进行步骤1513；

步骤1516，判断是否为虚拟资源调度供应。若是，进行步骤1517；否则进行步骤1525；

步骤1517，资源分配和配置服务。进行步骤1518；

步骤1518，虚拟资源供应服务。进行步骤1519；

步骤1519，业务QoS和错误服务。进行步骤1520；

步骤1520，软件化服务（capability/data model）使各个虚拟资源多路复用+空间共享调度，可解决超载或超出能力（Overcapacity）问题。进行步骤1521；

步骤1521，物理资源调度供应（硬件和软件）。进行步骤1522；

步骤1522，判断是否物理资源能力不足。若足，进行步骤1524；否则进行步骤1523；

步骤1523，物理资源QoS和错误服务。进行步骤1515；

步骤1524：正常返回；

步骤1525，判断是否物理资源调度供应。若是，进行步骤1526；否则进行步骤1530；

步骤1526，透过资源模型通道，接受从某个资源模型里的软件化服务所发来的设置资源指令。进行步骤1514；

步骤1527，物理资源节点实现资源多路复用调度。进行步骤1528；

步骤1528，物理资源节点实现资源空间共享调度。进行步骤1529；

步骤1529，物理资源节点把资源通知传给软件化服务。进行步骤1530；

步骤1530，判断是否全面业务自动化。若是，进行步骤1531或1534；否则进行步骤1543；

步骤1531，应用规划。进行步骤1532；

步骤1532，应用设计/更新。进行步骤1533；

步骤1533，缺陷/性能分析。进行步骤1539；

步骤1534，应用部署。进行步骤1535；

步骤1535，应用设计/更新。进行步骤1536；

步骤1536，QoS保障业务。进行步骤1537；

步骤1537，错误处理业务。进行步骤1538；

步骤1538，企业系统业务。进行步骤1539；

步骤1539，部属在基础设施资源上。进行步骤1540；

步骤1540，自动资源规划和运营（1）自动激活和配属资源，（2）自动QoS和错误管理。进行步骤1541；

步骤1541，按业务供应动态资源（1）供应隔离的虚拟网络；（2）供应隔离的虚拟服务器；（3）供应隔离的虚拟存储。进行步骤1542；

步骤1542，自动映射资源至物理网络且立即执行。进行步骤1524；

步骤1543：错误返回。

虚拟网络系统业务交付服务的方法

图16显示虚拟网络业务交付服务方法的流程图。业务交付服务包括业务的接入和业务交付本身。业务交付就是在逻辑网络上实现部署和卸载而不必碰触任何物理网络和其它物理资源。另外，交付点的服务包括物理POD，软件化（图11）和逻辑POD（图24）的建立。步骤如下：

步骤1601，业务交付服务的初始化。进行步骤1602；

步骤1602，判断是否处理接入。若是，进行步骤1603；否则进行步骤1611；

步骤1603，判断是否应用供应商。若是，进行步骤1604；否则进行步骤1608；

步骤1604，业务组件Mesh-up/API开放。进行步骤1605；

步骤1605，7层交换实现虚拟业务交付/实时业务域的自动化。进行步骤1606；

步骤1606，SDP业务构建系统。进行步骤1607；

步骤1607，按照业务工厂所提供的SPEC建立逻辑业务。进行步骤1610；

步骤1608，用户自助服务。进行步骤1609；

步骤1609，7层交换实现虚拟业务交付/实时业务域的自动化。进行步骤1610；

步骤1610，SDP业务交付。进行步骤1611；

步骤1611，判断是否业务交付。若是，进行步骤1612；否则进行步骤1614；

步骤1612，在逻辑核心网上快速部署、卸载；但不碰触企业物理网、物理资源。进行步骤1613；

步骤1613，运行在运营保障系统的监视下。进行步骤1618；

步骤1614，判断是否交付点服务。若是，进行步骤1615或1616或1617；否则进行步骤1619；

步骤1615，建立物理POD服务器:为计算、存储、网络物理资源建立物理POD（详情请看图12的说明）。进行步骤1618；

步骤1616，建立软件化服务器:融和、软件化数据中心的物理资源（虚拟网络、虚拟IT），形成POD驱动（详情请看图12的说明）。进行步骤1618；

步骤1617，建立逻辑POD服务器:为每个业务环境建立逻辑POD（详情请看图24，25的说明）。进行步骤1618；

步骤1618：正常返回。

步骤1619：错误返回。

应用保障系统

图17显示一个使用自动化、生命周期管系统的虚拟网络的结构图。用户可以超额订阅（oversubscription），但系统不能超载（overload或overcapacity）。监控这个超载的，就是一个网络应用保障系统(Application Assurance System)。应用保障系统之所以可以防止自动化的虚拟网络管理设备“超载”的原因，在于CPU级别的抢占权限，可以使用于虚拟化（图9）或非虚拟化（图18）的情况。当然，这个子系统还能产生告警（alarm）、报文(report)、以及防范故障（fault）。应该说，在未来虚拟网络完备的情况下，各种虚拟的、物理的计算资源、网络资源、存储资源和管理系统形成一个极为复杂的网络，单靠自动化管理而没有智能的自主管理是不切实际的。这里的应用保障系统所含的规则引擎只具有简单的规则，应该也具备前述的CEP或任何智能方法。

虚拟网络应用保障系统包括三个部分：中央采集控制系统（相当于ACRA自主系统架构中间层资源管理器），被管理资源主机以及主机上的Agents（相当于底层被管资源上的传感器sensor/效应器effector组）,和前台子系统(相当于集成控制台并具备有某些顶层的统筹管理器的功能)。

下面结合附图进行说明。

请参阅图17：网络应用保障系统(Application Assurance System)的功能的分层关系图，反映了该实施例的各功能之间的从属关系。它包括三大部分：前台子系统1710,中央采集控制系统1720，和以主机为单元的被管理资源1730。

前台子系统1710的功能包括:拓扑管理,分级管理,地址簿管理,告警管理,配置管理,性能管理,安全管理,策略管理,应用管理,报表管理,安全接入管理,高级服务器管理,环境管理,电源管理,和账户服务管理。其中告警管理,配置管理,性能管理与本发明密切相关。

中央采集控制系统1720包括后台核心引擎和运行支撑两大功能模块。其中,后台核心引擎包括下列功能:底层通信,网络拓扑发现,数据监控采集,专家库,信息库,接收服务,日志服务,接口。运行支撑包括下列功能:服务状态管理,查询服务,数据服务,三方接入接口。

被管理资源1730包括下列功能模块及功能:监控(性能监控,应用程序监控,主机监控),配置管理(服务器信息,日志级别,持久化信息),通信(管理功能,监视功能,策略处理,响应处理,事件触发),日志(Fatal故障日志,Debug调试日志,Warn提醒日志,Error错误日志,Info信息日志),策略(规则解析,策略处理),持久化(应用信息持久化,策略持久化,上报事件持久化),应用程序生命周期管理(虚拟化管理,状态管理,发现应用)。

虚拟网络的性能服务框架和性能监视器的结合架构

图18是虚拟网络的性能服务框架和性能监视器的结合架构图。本实施例是利用Linux的虚拟化架构实现了图17应用保障系统的监控部分，譬如在用户空间（userspace）和内核空间（kernel space）运行自主管理的MAPE组件（monitor,analyze,plan,execute），而以串口通道和客户空间（guest space）的虚拟机连系。专利保护的范围并不局限于这样的实现方法，譬如MAPE组件也可运行在虚拟机上（也就是客户空间），而且操作系统虚拟化环境也未必限定在Linux平台。

从自主管理的角度而言，图9陈述了传感器和效应器，是底层接触点（touch point），图18陈述了性能服务，是中间层的接触点管理器，图17陈述了应用保障系统，是上层的统筹管理器。

此外，图9所绘的是一个没有操作系统虚拟化的主机，而图18则有VMM。虽有不同，但就PMU从硬件监视CPU的角度而言，监视硬件的功能和相关的监视工具是类似的。

方框1810对应到图17的1710，是用户人机交互的管理。

方框1820对应到图17的1720，但强调网络的管理。自主管理MAPE运行的主机并不限于集群的Slave（网络的叶结点），也可以是集群的Master（非叶结点）。抢占性/关键任务的政策和一般应用的政策均可透过网络传输至任何节点。

其它以标码183起头的方框共有六个组成部分:

（1）方框1831传感器。也就是是监视器硬件组件，包括方框18311的PMU，18312的PMD，18313的PMC和18314的PMU驱动核心代码。这部分已在图9中陈述。

（2）方框1832性能监视器。方框18321是运行在用户空间的应用1到应用n；方框18322是监视器、其继承组件，及集合内的成员；方框18323是主机性能监视器，包括在用户空间运行的方框183231用户空间监视器，方框183232的内核空间监视器，以及183233的虚拟机串口通道，也属于18323主机性能监视器的一部分；方框18324是性能监视基础工具的应用接口（API）。虚拟机串口通道是Upcall和Hypercall以外的第二通道，方便快速简短信息的传输。这两个通道借助运行在虚机上的代理收集性能资讯，执行决策（例如停止虚机上的应用进程）。

以上（1）及（2）的细节请看汤传斌等人的中国专利201110141642.X“一种基于硬件基础工具监视虚拟化系统性能的架构及方法”。

（3）方框1833分析器。包括18331历史/统计性能数据库，18332规则库，和18333策略管理器。规则可以包括硬件规则和应用规则。集群中的主控主机（Master）还可包括网络流量调节规则。

（4）方框1834计划器。包括18341瓶颈辨认器，18342性能图形产生器，18343工作负荷调整器(也就是PDF，policy decision function)，和18344性能优化器。负荷调整器调整集群级别（cluster-intensive）和事务级别（transactional-intensive）的负荷，统筹全局系统的分析、当地应用的分析、并能利用抢占性中断的优势，处理进程生命周期的管理。

（5）方框1835执行器。包括18351各式PEP（policy execution point），以及18352基树遍历器。PEP存在于虚机、VMM和KVM中，借助基数遍历器执行1834计划器下达的指令。

（6）方框1836效应器。包括18361的OS任务调度器，18362的内存管理器，和18363内存硬件。这部分已在图9中陈述。

以上（3）（4）（5）及（6）的细节请看王彦新等人的中国专利201010183844.6“通过总线架构构建虚拟机监控器的方法和性能服务框架”里的性能服务框架系统。

一个网络应用保障系统的自主管理结构

请参阅图19。前台子系统1910实现了相当于ACRA自主系统架构中集成控制台加上某些的统筹管理器的功能。其功能中的告警管理,配置管理,性能管理实现了对中间层的自修复,自配置和自优化三类自主元素的全局性管理。ACRA自主系统架构顶层中的一些全局性管理被设计在前台子系统1910上而不是在中央采集控制系统1920的原因在于在自主管理系统在成熟的初期仍然需要进行大量的人工干预。只有当自主管理系统完全成熟后,才基本上不需要人工干预。这部分功能可以由中央采集控制系统1920来实现。

请参阅图19。中央采集控制系统1920实现了相当于ACRA自主系统架构中的中间层的功能。底层通信负责中央采集控制系统1920和被管理资源1930a或1930b以及前台子系统1910之间的通信联系,主要是事件的发送和接收。在系统的初始化阶段,网络拓扑发现功能将自动找出网络中所有被管理资源的拓扑信息包括主机,网络设备,应用程序,服务器,数据库等。这些信息将被存入知识库1925中。专家库包括功能有自修复,自配置和自优化三类自主元素的数据汇总,分析和计算,并进行故障关联性分析。这些功能运用人工智能的方法实现了ACRA自主系统架构顶层中某些的统筹管理器的功能(需要人工干预的部分功能在前台子系统1910中实现)。信息库功能包括全网资源信息,拓扑信息,配置信息和运行信息。它由自主元素中的知识库1925来实现。接收服务功能实现了自主元素中的Monitor部分1921。它是受事件驱动的。数据监控采集功能实现了Analyze部分1922和Plan部分1923之间含有额外的循环时的数据采集。它主动寻找所需信息的部分具有轮询(polling)的特征(但从整个自主管理过程角度来说还是事件驱动的)。而接口功能和三方接入接口由自主元素中的传感器（sensor）/效应器（effector）组来实现。

服务状态管理功能由Analyze部分1922和Plan部分1923来实现。查询服务功能是为前台子系统1910服务的,包括系统日志,业务日志,操作日志。日志服务功能并非由自主元素来实现。数据服务功能包括备份,迁移和恢复。它们由自主元素中的Execute部分1924来实现。

被管理资源1930a主机1上的监控功能包括性能监控,应用程序监控,主机监控由自主元素中的Monitor部分1931来实现监控。配置管理功能包括服务器信息,日志级别,持久化信息均由自主元素中的知识库1935来实现。通信功能包括管理功能,监视功能,策略处理,响应处理和事件触发由自主元素中的Execute部分1934来实现。日志功能包括Fatal日志,Debug日志,Warn日志,Error日志,Info日志均存储在自主元素中的知识库1935中并与知识库1925共享。策略功能包括规则解析,策略处理由自主元素中的Analyze部分1932和Plan部分1933来实现。持久化功能是指一些本地（主机上每个VM）策略，如应用信息持久化,策略持久化,上报事件持久化等，它们均由自主元素中的知识库1935来实现。Agent 1,2,31937即是自主元素的传感器sensor/效应器effector组。

需要注意的是，图9被管理资源1930a主机1和1930b 主机m的结构均已简化。在1930a主机1上有三个VM 1938(即VM1,VM2,VM3),而现实中可以有任意多个(当然在系统允许的情况下)。应用程序生命周期管理功能包括虚拟化管理,状态管理,发现应用即是在1930a主机1上管理VM 1938的。其部分功能在VMM 1936的支持下实现。

图19被管理资源1930a主机1上有完整的本地自主元素。它使主机1能在与中央采集控制系统1920的联系切断(如通信失败)的情况下,根据本地策略做到某种程度的自我管理。主机1和图1自主系统架构中底层左边的自主元素相一致。

图19被管理资源1930b主机m上所示的自主元素则不完整。它没有Analyze部分,Plan部分以及知识库部分(即没有本地策略),因此主机m不能做到自我管理。它只为中央采集控制系统1920的Monitor部分1921提供子级Monitor;为中央采集控制系统1920的Execute部分1924提供子级Execute。

请参阅图19。知识库1935中定义了Monitor1931所监视的被管理资源类型,包括:主机,Application,User,Switch,Router,Firewall,Domain Controller,Load Balancer,UPS,Printer,Virtual Device,等等。其中虚拟设备Virtual Device是我们最关心的。它是本发明所应用的首要目标。而具体所监视的属性,也就是Monitor 1931输入事件的类型包括:CPU_RATE(cpu利用率),MEM_RATE(memo利用率),DISK_QUOTA(disk用量),NETWORK_RX(network receive),NETWORK_TX(network transmit),CASHE_MISSED(高速缓存未命中频度),CONTEXT_SWITCH(上下文切换频度),PAGE_FAULT(页错误频度),BRNCH_MISSES(分支预测失误率),CPU_MIGRTIONS(CPU迁移次数),ALIGMENT_FAULTS(字对齐错误次数),EMULATION_FAULTS(指令软模拟次数),CDI(平均每条指令有效执行的时钟周期),LDST(内存操作指令占总指令的百分比),RESST(CPU因等待其他资源而阻塞的时钟周期占总周期的百分比),BRNCH(分支指令的百分比),BRMISS(分支误测占分支指令的百分比),L2_CACHE_MISSES(访问L2未命中的百分比),BUS_REATE(bus传输任何类型数据的利用率),BUS_DATA(bus传输cpu mem类型数据的利用率),BNR(因总线忙而引起的总线不能传输的百分比),SIMD(SSE指令的百分比常用64位),EFFECTIVE_INSTR(有效指令数),PIPELINEBLOCK(pipeline 阻塞),SYSTEM_CALL_NUM(系统调用次数),等等。

由于我们介绍实施例的主要目的在于证明本发明的实用性,所以我们在这里没有必要对每个被管理资源类型以及所监视事件的类型的处理过程一一赘述。我们仅举一例加以描述,而其余类型的处理过程读者可以根据同样方法加以类推。

子级Monitor作CPU利用率超常判定和子级Execute发出警告

请参阅图20。假如我们规定主机m上的VM n的CPU利用率为Unhalted_Core_Cycles/(CPU_frequency*Number_of_cores*3600)(seconds))*100,CPU利用率计算间隔时间为30秒,CPU利用率值大于90%就被认为超常。如果CPU利用率连续超常五次就应当发出警告Alarm。CPU利用率超常判定过程请请参见图20。其中Unhalted_Core_Cycles,CPU_frequency和Number_of_cores值由图19中VM n的Agent n取得,CPU利用率计算和超常由Monitor来完成。警告Alarm则由Execute来发出。

CPU利用率超常警告后的流程

图21是CPU利用率超常警告后的流程图。当上述警告Alarm送达中央采集控制系统自主管理者的Monitor 1921后,Analyze 1922作初步分析,Plan 1923进一步搜集关于VM n的信息。如果从VM n发来的补充信息表明VM n上的processes正常,则说明VM n占用CPU资源较多,可以考虑将它(活)迁移到其它的主机上;如果从VM n发来的补充信息表明VM n上的某个process已死,则VM n可以根据一段时间(如10分钟)前的snapshot重新启动,或者整个VM n迁移到其它的主机上后根据snapshot重新启动。

自主虚拟网络系统

图22是一个自主虚拟网络的架构图。

自主虚拟网络系统结合了前述的发明：

三个有关虚拟化自主管理系统的基础发明：（1）自主管理系统（图3，图4A，图4B），包括自主管理系统的虚拟化（图8）；（2）抢占性接触点系统（图9）；（3）软件化服务系统（图11）；和

一个有关虚拟网络系统（图13，图14）的发明，包括应用保障系统（图17，图18）。

此外，虽然前面已借用应用保障系统的实施例说明自主管理在这样一个子系统中所能扮演的角色（图17和图18），但自主虚拟网络还涵盖其它基本组件：物理POD，软件化服务，逻辑POD，和其它业务交付服务，以及用户代理，都可以是自主管理。这样的五层结构扩展了经典的ACRA三层结构。更抽象的说，ACRA的三层结构，可以是n层，上层与下层之间的关系是：他们具有类似的MAPE组件，但下层处理相对局部的事件，上层处理相对全局的事件。分述如下：

（1）方框221物理POD服务器。详情见图11和图12的陈述。

（2）方框222软件化服务器。详情见图11和图12的陈述。

（3）方框223逻辑POD服务器。逻辑POD多路复用软件化服务器中的资源，

详情见图24的陈述。

（4）业务交付平台224。包括：

a)业务服务器2241，功能包括存储、版本、业务保障、FCAPS、配置、数据分析预测、部署/激活/卸载、业务规划/调度等问题的管理。FCAPS是计算机网络管理系统的五个子系统，代表故障（fault）管理，设置（configuration）管理，计费（accounting）管理，性能（performance）管理，和安全（security）管理。

b)自动化部署服务2242。详情见图15的陈述。

c)业务生命周期管理2243，包括业务设计、部署、运行、卸载的周期管理。

d)分布式业务汇聚2244。

e)业务环境供应2245。逻辑POD的实例（instance）与业务实例（serviceinstance）是1-1对应，订阅虚拟资源，进而订阅分布式物理资源。以双箭头实线表示。

f)业务设计2246。

（5）使用者225。包括系统管理员2251（网络资源管理员22511、存储资源管理员22512、计算资源管理员22513），业务运营2252，企业业务用户2253，企业项目管理办公室2254。这些都是所谓的用户代理（UserAgent，UA），具备智能的自主管理能力和图形界面。

（6）会话协议标志226，以粗而短的实线表示。支持分布式以及汇聚的实时会话，详情见图23的陈述。

（7）自主管理标志227。有关物理POD服务器和软件化服务器利用自主管理的说明，请参阅图11和图12的陈述。逻辑POD服务器利用自主管理实现与软件化服务器之间推与拉的资源调度。业务交付平台利用自主管理实现与多个逻辑POD服务器之间的操作有关资源的竞争（operation competition forresources），并利用自主管理实现与多个用户代理之间的操作请求有关资源的竞争（operation request competition for resources）。

用于自主虚拟网络的SIP协议

图23是用于自主虚拟网络的会话初始协议（SIP，session initiation protocol）的流程图。本实施例虽然使用SIP说明，但其概念也适用于其它类似的或未来的通讯协议。虚拟网络因SIP而能完成业务规划／设计环境完整性和QoS保证。SIP是有状态的（stateful），在点对点（point-to-point）的通讯中能处理故障后的恢复、能利用Proxy/Gateway跨虚拟网络集群、并能封装（encapsulate）、传输其它虚拟网络协议的荷载。注意状态有两种：（甲）凡是协议都有通讯的状态，（乙）但这里强调的是荷载里的状态，是相关物理或逻辑资源的状态，库存在VFSM的MIB里。当所述资源的状态发生变化，SIP要重新发送Invite指令。所以步骤2312是相当关键的一步。

步骤2301：判断是否为SIP指令Invite。若是，进行2302；否则进行2303；

步骤2302：建立Dialog，一个Dialog代表一个应用，可以有多个服务（即Dialog的Legs）。进行2322；

步骤2303：判断是否为SIP指令subscribe。若是，进行2304；否则进行2306；

步骤2304：在Header中设定用户的Call ID，Dialog的Legs以Tag表示。进行2305；

步骤2305：利用VIA字节，穿越多个Proxy时，记录、保留传输状态及历史。进行2322；

步骤2306：判断是否为SIP指令presence。若是，进行2307；否则进行2308；

步骤2307：同步check points。进行2321；

步骤2308：判断是否为SDP指令。若是，进行2309；否则进行2319；

步骤2309：以定制化的SDP传递荷载内容。进行2310；

步骤2310：Header中设定会话对象，例如进程、线程、时间片、服务、服务线程。进行2311；

步骤2311：利用VIA字节，穿越多个Proxy时，记录、保留荷载里的状态及历史。进行2312；

步骤2312：判断是否荷载里的状态有变化。若是，进行2302；否则进行2313；

步骤2313：判断是否介于业务交付平台和用户之间。若是，进行2314；否则进行2315；

步骤2314：用户请求首先产生接入会话（access session），主要荷载为用户的请求及最后回应。进行2323；

步骤2315：判断是否介于逻辑资源POD和业务交付平台之间。若是，进行2316；否则进行2317；

步骤2316：接入请求被验证通过后产生服务会话（service session）。主要荷载为被竞争、选取、隔离的逻辑资源。进行2323；

步骤2317：判断是否介于软件化服务器和逻辑资源POD之间。若是，进行2318；否则进行2319；

步骤2318：在服务会话中，逻辑POD与用户请求的业务绑定（bind）。当业务完成后，不再绑定（unbind）,此时服务会话也结束。主要荷载为已被软件化服务器融合的物理资源，成为逻辑资源；进行推和拉调度的荷载。进行2323；

步骤2319：判断是否介于物理资源POD和软件话服务器之间。若是，进行2320；否则进行2324；

步骤2320：主要荷载为将被融合的物理资源、预定义的状态改变和notify。进行2323；

步骤2321：判断是否为SIP指令bye。若是，进行2322；否则进行2324；

步骤2322：Dialog结束。进行2323；

步骤2323：正常返回；

步骤2324：错误返回。

逻辑POD服务器

图24是逻辑POD服务器的流程图。

逻辑POD服务器包含多个逻辑POD。每个逻辑POD有三种不同的供应方案：

（1）除了共享空间（space-sharing）的特性，分时（time-sharing）的逻辑POD还支持“虚拟服务器”，而该虚拟服务器可以超额订阅（over-subscribe）物理的主机服务器。此外，每个虚拟服务器相对于其他虚拟服务器，彼此之间可以具有不同的硬件规格。譬如，一个英特尔VT-i的物理主机上，可以在不同时间运行两个分时的虚拟服务器，其中一个硬件规格为VT-x和被缓存的PCI-x，另一则仅为VT-x。物理的主机服务器对于供应实例（provisioning instance）来说是不可见的。

（2）除了虚拟服务器的规格可以被随需（on-demand）提供以外，该虚拟服务器的操作系统也可以被随需供应在每个虚拟机上。

（3）除了虚拟服务器的操作系统可以被随需提供以外，应用程序服务器（Application Server,AS）可以被随需供应在每个被超额订阅的操作系统上。步骤如下：

步骤2401：逻辑POD服务器初始化。进行2402；

步骤2402：判断是否面向业务交付平台。若是，进行2403；否则进行2408；

步骤2403：接受业务交付平台传来的资源操作请求事件，逻辑POD多路复用（multiplex）虚拟资源融合网络中的资源。进行2404；

步骤2404：根据VFSM执行器方法和VFSM规则库，解决多个业务逻辑POD之间的资源竞争问题。进行2405；

步骤2405：判断是否多个逻辑POD在本服务器的资源充足。若是，进行2406；若是操作竞争，否则进行2407；

步骤2406：比较软件化服务器可用的资源、和POD服务器里的各业务逻辑POD需求，在QoS下得出竞争结果。进行2413；

步骤2407：通知业务交付平台，请求更多资源。进行2413；

步骤2408：判断是否面向软件化服务器。若是，进行2409；否则进行2414；

步骤2409：根据资源调度规则库里的规则，执行软件化服务器和逻辑POD服务器之间的“推”“拉”调度。进行2410；

步骤2410：判断为何种调度。若是推调度，进行2411；若是拉调度，进行2412；

步骤2411：推调度不管物理POD的能力而承诺资源的变化要求。支持并行化的资源供应。进行2420；

步骤2412：拉调度：拉调度只有当物理的POD容量准备好时才承诺资源的变化要求。支持并行化的资源供应。进行2420；

步骤2413：正常返回；

步骤2414：错误返回。

业务交付平台与用户的互动

图25显示业务交付平台与用户互动的流程图。业务交付平台接受来自不同用户的请求。如果是各种网管人员的硬件资源操作请求，则按照简单QoS规则得出竞争结果。如果是企业业务人员，则进入业务生命周期管理。如果是业务运营人员（例如应用开发商）则进入部署自动化。如果是PMO，则进入订阅服务，由业务服务器的MAPE引擎做多部门、多业务的汇聚，供应业务环境，使PMO可以做业务设计。（MAPE引擎也就是前述的自主管理者，由4个MAPE组件所组成的自主管理软件。）如果是与逻辑POD服务器的交流，则按照MAPE引擎计算的结果向逻辑POD服务器下达指令，而另一方面，也接受逻辑POD服务器逻辑资源不足的通知，转告MAPE引擎。

业务服务器的MAPE引擎犹如自主管理的统筹管理器。它的MAPE组件是全局的（而逻辑POD服务器的MAPE组件则是服务器当地的），它的规则库除了考虑逻辑POD服务器之间资源的竞争，还要考虑从用户来的业务需求。

流程步骤如下：

步骤2501：业务交付平台初始化。进行2502；

步骤2502：判断是否面向用户。若是，进行2503；否则进行2515；

步骤2503：判断是否用户为系统/网管人员。若是，进行2504；否则进行2505；

步骤2504：接受来自不同系统/网管人员（IT、存储、网络、服务器）的业务操作请求，经由简单QoS规则比较后，得出竞争结果（谁的请求先处理，谁的请求要等待）。进行2507；

步骤2505：判断是否用户为企业业务（使用）人员（譬如网络操作中心NetworkOperation Center，NOC的操作员）。若是，进行2506；否则进行2508；

步骤2506：进入业务生命周期管理。进行2507；

步骤2507：进入业务服务器MAPE引擎。进行2528；

步骤2508：判断是否用户为业务运营人员（例如应用开发商，负责安装、维修该业务的应用软件）。若是，进行2509；否则进行2510；

步骤2509：进入部署自动化服务。进行2507；

步骤2510：判断是否用户为业务PMO（例如该业务的项目经理）。若是，进行2511；否则进行2516；

步骤2511：业务实例与逻辑POD一一对应，订阅虚拟资源（进而订阅分布式物理资源）。进行2512；

步骤2512：进入业务服务器MAPE引擎。进行2513；

步骤2513：基于部门/业务的服务分布式汇聚。进行2514；

步骤2514：供应业务环境。进行2515；

步骤2515：提供给PMO业务设计。进行2528；

步骤2516：判断是否为业务服务器MAPE引擎。若是，进行2517；否则进行2523；

步骤2517：判断是否为订阅服务或逻辑POD通知。若是，进行2518；否则进行2519；

步骤2518：业务服务核心：配置、激活、部署、卸载、业务保障、业务调度、FCAPS管理等等。进行2528；

步骤2519：全局统筹订阅服务需求，和各POD服务器里的各业务逻辑POD需求，在QoS下得出竞争结果。进行2520；

步骤2520：根据VFSM规则库，由VFSM执行器计算业务状态（在线、离线、设计、已删除），以解决多个业务逻辑POD的服务器之间的资源竞争问题。进行2521；

步骤2521：判断是否整体业务交付平台硬件能力充足。若是，进行2528；否则进行2522；

步骤2522：通知系统/网管部门，申购硬件资源。进行2528；

步骤2523：判断是否面向逻辑POD服务器。若是，进行2524；否则进行2529；

步骤2524：判断是否向Pod服务器下达逻辑资源指令。若是，进行2525；否则进行2526；

步骤2525：将MAPE引擎执行后所得结果通知逻辑POD服务器，比较不同业务操作，在QoS下得出竞争结果。进行2528；

步骤2526：判断是否接受POD服务器的通知。若是，进行2527；否则进行2529；

步骤2527：转告MAPE引擎。进行2528；

步骤2528：正常返回；

步骤2529：错误返回。

集群环境下POD的形成

图26显示集群环境下POD的形成的流程图。虚拟网络可以是（1）简单的“多客户单服务器”，或是（2）“多客户n层拓扑”（n-tier topology，譬如前置Web服务器、应用服务器、数据库服务器以及后台存储设施），可以异构。然而，网络也可以是（3）“多客户集群拓扑”（cluster topology），其中成千上百的主机分别归属于不同集群。在集群拓扑的大数量主机中，节点集群的Slave节点容许有限失效；一般Master-Slave群均为同构；集群需支持负载均衡；物理资源首先可以分割成许多物理POD，每个物理POD可以有多个集群；而逻辑POD也因不同用户的设计而可以有多个。虽然主机未必都被虚拟化，但逻辑POD提供OS-on-Demand的服务，可以在主机上迅速部署虚拟机。步骤如下：

步骤2601：判断是否形成物理POD。若是，进行2602；否则进行2603；

步骤2602：将物理的集群（簇）分割成几个物理的POD或单个物理POD。进行2615；

步骤2603：判断是否形成逻辑POD。若是，进行2604或2605；否则进行2610；

步骤2604：基于原有的单个物理集群：逻辑的PODS仅限于单个集群。进行2606；

步骤2605：基于多个集群：没有上述限制。进行2606；

步骤2606：此二选择作为配置选项提供给用户。进行2607或2608；

步骤2607：仅共享空间的逻辑POD不会虚拟化服务器，这将确保计算的高质量和系统的性能。进行2609；

步骤2608：随需操作系统（OS-on-demand）的逻辑POD会虚拟化服务器，提供更多元化的开发/测试设备。进行2609；

步骤2609：此二选择作为配置选项提供给用户。进行2615；

步骤2610：判断是否为逻辑POD与应用的连接。若是，进行2611；否则进行2613；

步骤2611：连接到业务交付平台的每个逻辑POD均带有版本号。进行2612；

步骤2612：使用业务交付平台的存储系统来实现存放和恢复。进行2615；

步骤2613：判断是否为逻辑POD与软件化服务器连接。若是，进行2614；否则进行2616；

步骤2614：使用拉(Pull)调度来实现对后台资源的承诺，以避免网络流量爆发。进行2615；

步骤2615：正常返回；

步骤2616：错误返回。

在本发明的实施例中，公开了一种设计和构造多循环自主管理者的系统，包括设计装置和与之相连的构造装置，其中设计装置在分析和规划这两部分的中间增加至少一个额外的循环，多循环自主管理者是对经典的自主元素模型中的自主管理者的一种扩展。而构造装置是多循环自主管理者用诊断流程图表示故障诊断工作的步骤，故障诊断工作是循环往复多次“产生假设→进行调查→发现结果→得出结论”的过程，最终得出最后故障诊断结论。多循环自主管理者在自主计算参考架构下，形成混合式自主计算参考架构。

对应的，本发明公开了一种多循环自主管理者的实现方法的实施例，在实现方法中，将诊断流程图中的每一步骤作为一个事件，将诊断流程图中的各个步骤运行之间的连接作为一个活动，并据此将诊断流程图转换成事件驱动流程方框图。

将事件驱动流程方框图中的事件映射到一个自主管理者中，以使该自主管理者的分析和规划部分都可以用一组规则来表示，其中规则由复杂事件处理技术实现，自主管理者在自主计算参考架构下，形成混合式自主计算参考架构，自主管理者的每一部分包括复杂事件处理引擎的实例，每个实例中可以包含有多条规则。

自主管理者通过事件驱动方法实现，所述复杂事件处理引擎的每个实例是一个事件处理代理，所述自主管理者是由四个事件处理代理连接而成，由所述事件处理代理来构建的所述自主管理者在分析和规划这两部分中间增加了至少一个额外的循环，所述自主管理者是对经典的自主元素模型中的自主管理者的一种扩展。

在本实施例的实现方法中，多循环自主管理者保存、搜索事件处理代理规则库里的规则，保存过去的经验，并自动学习得到新规则。监视器事件处理代理形成至少一个规则的事件列，保存在事件处理代理规则库中。分析器事件处理代理搜索当前符合刺激的事件列，如果成功以分数匹配到最相似的假设，否则回到监视器。计划器事件处理代理识别目标、目标参数，搜索符合目标与元状态的假设，如果成功则把失败经验存入规则库而且以分数匹配到最相似的修复计划，否则回到分析器。执行器事件处理代理搜索符合策略的修复计划，如果成功则利用分数匹配到最佳执行计划，否则回到计划器。

在本实施例中，自主计算参考架构包括底层、中间层和顶层，其中自主计算参考架构的底层包含有虚拟的和物理的网络设备,虚拟的和物理的网络设备作为被管资源存在自主计算参考架构中,部份被管资源本身就含有自我管理的属性。

自主计算参考架构的中间层则是大量的由事件处理代理来构建自主管理者的自主元素，每个自主元素代表一项原本由IT人工进行的管理工作，这些自主元素作为资源管理器存在于自主计算参考架构中,自主元素实现自配置、自优化和自修复中的某一类任务。自主计算参考架构的顶层包含有统筹各种中间层资源管理器的统筹管理器，统筹管理器控制全局系统范围的自主管理。

本发明中还公开了一种虚拟化的自主管理系统的实施例，虚拟化的自主管理系统包括：镜像部署模块、接触点模块、硬件虚拟化模块。镜像部署模块中，自主管理者本身经由应用虚拟化的组件拆分和重组，直接部署在物理机或虚拟操作系统的镜像上，直接部署的传输使用串流技术，在镜像上的虚拟自主管理系统组件经由差分技术，随时在自主计算参考架构的底层、中间层、顶层这三层架构之间同步。

接触点模块包括自主管理者的传感器和效应器，运行在被操作系统虚拟化的主机虚拟机监视器和硬件层里，具有主机虚拟机监视器底层环０的安全权限和抢占性，为即将造成故障而无抢占性的进程发出预警，进行预防措施。

硬件虚拟化模块，自主管理者利用硬件虚拟化管理物理和虚拟资源，硬件虚拟化利用软件化服务器中的虚拟有限状态机保存，搜索当前物理资源和逻辑资源的状态，自主计算参考架构的中间层资源管理器由各类自主管理者构成，资源管理器管理虚拟资源和物理资源,虚拟资源包括虚拟服务器、虚拟交换机、虚拟网卡，物理资源包括物理交换机。

镜像部署模块、接触点模块、硬件虚拟化模块为任何自主管理系统所实现，包括前述的多循环自主管理系统。

本发明还公开了一种具有抢占性权限的接触点系统的实施例。接触点包括传感器和效应器，运行在操作系统或虚拟机内核，具有内核环０的安全权限。传感器接收从硬件传来的刺激时，判断可能的故障。效应器进入内核的中断服务例程，具有内核环０的安全权限和抢占性，控制内核级别环1-3的内存管理器、周边设备管理器和任务调度器，以终止、重启、改变时间片或活迁移运行在操作系统或虚拟机上无抢占性权限的进程。

本发明还公开了一种智能的环0接触点实现方法的实施例。方法包括：

传感器实施进程级别的监视，使用多路复用的方法，以使被监视的事件数超过性能监视单元计数器数量的情况下仍可监视，传感器也实施系统级别的监视，包括监视转换后援缓冲器丢失、PCI总线延迟及流量、CPU停顿周期、内存访问延迟、设备访问延迟和缓存指令停顿。

在本实施例中，方法还包括依赖于操作系统平台的方法：

本发明还公开了一种将硬件资源软件化的服务方法的实施例中。在服务方法的实施例中，自主管理者拦截多个并发的请求，将请求映射到一个虚拟有限状态机，并使用虚拟有限状态机计算出物理资源的能力，把能力映射给物理机，最后物理机实现请求。

在本实施例中，首先物理交付点的监视器侦测到硬件资源需要变化的事件后，将事件转发给软件化服务器。软件化服务器的监视器接到该事件后，触发虚拟有限状态机执行器。虚拟有限状态机执行器向虚拟有限状态机规则库查阅规则，并根据当前资源状态，判断系统是否有能力实现该事件的请求。虚拟有限状态机执行器根据判断结果，变迁当前资源的状态，并执行行动。软件化服务器获得当前状态和行动，并得知能力。软件化服务器为了实现物理交付点资源的供应，提供新的数据和服务参数。软件化服务器获得当前能力，并设置新的状态，状态的更新触发虚拟有限状态机执行器。虚拟有限状态机执行器输入当前资源的状态、服务数据和服务参数，并从虚拟有限状态机规则库查阅新服务和参数。虚拟有限状态机执行器判断出物理交付点应有的新进入服务，由服务模块将服务数据和服务参数传输给物理交付点。物理交付点的服务模块完成新的供应，回应最初被拦截的请求。

本实施例还公开了一种软件化服务器的实现方法的一实施例，本实施例的实现方法包括：

物理交付点和软件化服务器形成一个客户端/服务器架构，按照自主管理的自主计算参考架构、软件化服务器的全局组件和客户端的物理交付点的当地组件呈一一对应，实现具有资源属性和状态的虚拟有限状态机，虚拟有限状态机执行器，虚拟有限状态机规则库和/或虚拟有限状态机监视器。

软件化服务器是基于虚拟有限状态机对于内网和外网资源进行能力计算，其中虚拟有限状态机可以用于系统设计时或运行时。

虚拟有限状态机执行器根据满足资源状态、服务质量和虚拟有限状态机规则所建立的虚拟有限状态机模型方法计算能力、执行事件。

虚拟有限状态机规则引擎按照智能的多循环复杂事件处理方法，进行虚拟有限状态机规则库的存储、调整、和搜索。

本实施例还公开了一种业务交付的虚拟网络系统的一实施例。在本实施例中，虚拟网络系统包括六个部分：企业环境设计和规划装置、企业环境交付管理装置、企业环境在线交付和运营保障装置、IT资源设计和规划装置、IT资源交付管理装置、IT资源在线交付和运营保障装置。

企业环境设计和规划装置是在业务环境下与业务程序管理办公互动的业务设计服务和与业务用户互动的业务订阅服务应用，修改增强电信运营图里有关业务的策略/承诺和基础设施的生命周期管理。

企业环境交付管理装置是在业务的离线逻辑环境中应用，修改增强电信运营图里的产品生命周期管理业务运营准备和支撑。

企业环境在线交付和运营保障装置是在业务的在线交付环境以及应用保障系统的业务管理部分应用，修改增强电信运营图里的业务合约履行和业务保障。

IT资源设计和规划装置是在系统管理员的资源设计服务中应用，修改增强电信运营图里有关资源的策略/承诺和基础设施的生命周期管理。

IT资源交付管理装置是在未分配的虚拟和物理资源中应用，修改增强电信运营图里的产品生命周期管理和资源运营准备和支撑。

IT资源在线交付和运营保障装置是在已分配虚拟和物理资源的在线交付环境以及应用保障系统的资源管理部分中应用，修改增强电信运营图里的资源合约履行和资源保障；其中已分配虚拟资源具有虚拟资源的独占和共享支持，所述虚拟资源汇聚不同位置、配置的物理资源，实现物理资源类型、部署无关化的资源融合，所述物理资源实现于企业业务划分的数据中心和物理资源网络，支持订阅交付，同时支持按空间分享和按时间分享物理资源，包括许多未分配和已分配的网络、存储、计算物理资源。

本发明还公开了一种业务交付虚拟网络系统的自动化方法的一实施例。本实施例的自动化方法包括：用户业务调度供应、虚拟资源调度供应、物理资源调度供应、全面自动化服务。

用户业务调度供应包括计算、存储、网络资源的需求设计服务、系统资源分析服务、虚拟资源预约和部署服务、进行虚拟资源调度供应，若资源能力不足，则进行服务质量和错误服务，最后进入业务交付服务。

虚拟资源调度供应包括虚拟资源分配、配置、供应服务、软件化服务、进入物理资源调度供应，若资源能力不足，则进行服务质量和错误服务，最后进入业务交付服务。

物理资源调度供应包括接收软件化服务的设置资源指令，实现资源多路复用、资源空间共享、资源通知传回软件化服务。

全面自动化服务包括应用规划和应用部署、自动资源规划和运营，按业务动态供应资源，并自动映射资源至物理网络，且立即执行。

本实施例中的业务交付服务包括：处理接入过程、业务交付过程、建立交付点过程。

处理接入过程包括：用户若是应用供应商，则将业务组件聚合，或者将应用接口公开；实现7层交换实现虚拟业务交付/实时业务域的自动化，并按照业务工厂所提供的规格建立逻辑业务；用户若是个人，则采用自助服务实现7层交换实现虚拟业务交付/实时业务域的自动化。

业务交付过程包括：在逻辑核心网上快速部署、卸载，但不碰触企业物理网、物理资源，业务运行在保障系统的监视下。

建立交付点过程包括：为计算、存储、网络的物理资源建立物理交付点，建立软件化服务器，融合数据中心的物理资源，形成交付点驱动，为每个业务环境建立逻辑交付点。

本实施还公开了一种自主管理的虚拟网络应用保障系统的一实施例。本实施例中的系统包括：中央采集控制系统、被管理资源主机以及主机上的代理、后台子系统。

中央采集控制系统相当于自主计算参考架构中间层资源管理器。被管理资源主机以及主机上的代理相当于底层被管资源上的四个性能服务组件：监视器、分析器、计划器、和执行器，以及两个接触点：传感器和效应器。后台子系统相当于集成控制台并具备有某些顶层的统筹管理器的功能。

本实施例中的性能服务组件：运行的主机是集群的从机，即网络的叶结点，或是集群的主控主机，即非叶结点，抢占性/关键任务的政策和一般应用的政策均通过网络传输至任何节点。

分析器的规则包括硬件规则和应用规则，集群中的主控主机还可包括网络流量调节规则。

计划器里的负荷调整器调整集群级别和事务级别的负荷，统筹全局系统的分析、当地应用的分析、并利用抢占性中断的优势，处理进程生命周期的管理。

在本实施例中，如果主机实行操作系统虚拟化，则监视器运行于虚拟机内和／或用户层，执行器运行于虚拟机内和／或用户层，虚拟机串口通道和Upcall/Hypercall形成两个通道，方便快速简短信息的传输,此二通道借助运行在虚机上的代理收集性能信息，执行决策。

本实施例公开了一种使用自主管理的网络应用保障系统的实现方法的实施例，具有虚拟网络设备自主管理部分。本实施例的实现方法包括：

前台子系统实现相当于自主计算参考架构中集成控制台加上统筹管理器的功能，功能中的告警管理、配置管理、性能管理实现了对中间层的自修复,、自配置和自优化三类自主元素的全局性管理，自主计算参考架构顶层中的全局性管理被设计在前台子系统上。

中央采集控制系统实现相当于自主计算参考架构中的中间层的功能，在系统的初始化阶段,网络拓扑发现功能自动找出网络中所有被管理资源的拓扑信息包括主机、网络设备、应用程序、服务器、数据库，拓扑信息将被存入专家库中，专家库的功能包括有自修复、自配置和自优化三类自主元素的数据汇总、分析和计算,并进行故障关联性分析，功能运用人工智能的方法实现自主计算参考架构顶层中的统筹管理器的功能。

被管理资源主机上有完整的本地自主元素，本地自主元素使主机能在与中央采集控制系统的联系切断的情况下,根据本地策略做到自我管理。

有些被管理资源主机上的自主元素则不完整，不完整的自主元素没有分析部分,计划部分以及知识库部分,不完整的自主元素对应的主机不能做到自我管理，只为中央采集控制系统的监视部分提供子级监视，为中央采集控制系统的执行部分提供子级执行。

本发明公开了一种自主管理的虚拟网络系统的一实施例。本实施例的系统包括：自主管理的硬件交付点装置、自主管理的软件化服务装置、自主管理的逻辑交付点装置、自主管理的业务交付平台装置、自主管理的用户代理装置。

自主管理的逻辑交付点装置中，多路复用软件化服务器中的资源利用自主管理实现与软件化服务器之间进行推与拉的资源调度。

自主管理的业务交付平台装置包括部署自动化、应用生命周期管理、和业务服务、订阅服务，业务交付平台装置利用自主管理实现与多个逻辑交付点服务器之间的操作有关资源的竞争，并利用自主管理实现与多个用户代理之间的操作请求有关资源的竞争。

自主管理的用户代理装置包括系统管理员、业务运营人员、企业业务用户、企业项目管理办公室，所述用户代理具备智能的自主管理能力和图形界面。

本发明公开了一种自主管理的虚拟网络系统的实现方法的一实施例。本实施例的实现方法包括：基础自主管理实现方法、虚拟网络实现方法、自主管理虚拟网络特有的实现方法。自主管理虚拟网络特有的实现方法包括会话协议、逻辑交付点服务、业务交付平台和集群拓扑。

而会话协议包括：虚拟网络因会话协议而能完成业务规划／设计环境完整性和服务质量保证，会话协议是有状态的，在点对点的通讯中能处理故障后的恢复、能利用Proxy/Gateway跨虚拟网络集群、并能封装、传输其它虚拟网络协议的荷载。以一个会话代表一个企业应用，子会话代表应用里的多个服务，会话包的头里含有用户身份、穿越各代理的传输历史纪录，会话的指令同步检查点。其它虚拟网络协议的荷载里，如果有资源状态的改变，则导致会话协议重新发送协议指令，传达资源状态的改变事实，如果会话协议为会话初始协议，将会重新发送邀请指令。其它虚拟网络协议的荷载内容为：若协议是介于用户代理和交付平台之间，用户请求首先产生接入会话，主要荷载为用户的请求及最后回应；若协议是介于交付平台和逻辑交付点服务器之间，接入请求被验证通过后产生服务会话，主要荷载为被竞争、选取、隔离的逻辑资源；若协议是介于逻辑交付点服务器和软件化服务器之间，在服务会话中，逻辑交付点与用户请求的业务绑定，当业务完成后不再绑定,此时服务会话也结束，主要荷载为已被软件化服务器融合的物理资源，成为逻辑资源；进行推和拉调度的荷载；若协议是介于物理交付点和软件化服务器之间，主要荷载为将被融合的物理资源、预定义的状态改变和通知。

上述逻辑交付点服务器为：逻辑交付点服务器包含多个逻辑交付点，每个逻辑交付点有三种不同的供应方案：

除了共享空间的特性，分时的逻辑交付点还支持虚拟服务器，而虚拟服务器超额订阅物理的主机服务器，每个虚拟服务器相对于其他虚拟服务器，彼此之间具有不同的硬件规范，物理的主机服务器对于供应实例来说是不可见的；

上述的逻辑交付点的实现步骤如下：

业务交付平台接收来自不同用户的请求，如果是网管人员的硬件资源操作请求，则按照简单服务质量规则得出竞争结果，如果是企业业务人员，则进入业务生命周期管理，如果是业务运营人员则进入部署自动化，如果是程序管理办公，则进入订阅服务，由业务服务器的引擎做多部门、多业务的汇聚，供应业务环境，使程序管理办公做业务设计，如果是与逻辑交付点服务器的交流，则按照引擎计算的结果向逻辑交付点服务器下达指令，而另一方面，也接收逻辑交付点服务器逻辑资源不足的通知，转告引擎。

业务服务器的组件是全局的，而逻辑交付点服务器的组件则是服务器当地的，业务服务器的引擎的规则库除了考虑逻辑交付点服务器之间资源的竞争，还考虑从用户来的业务需求。

业务服务器面向项目运营用户时，进行业务生命周期管理，业务项目服务器处理配置、激活、部署、卸载、业务保障、业务调度。

业务服务器面向逻辑交付点时，逻辑交付点与业务项目是一一对应，以便程序管理办公用户订阅虚拟资源，进而订阅分布式物理资源，业务服务器供应业务环境并提供给程序管理办公业务设计。

虚拟网络的集群拓扑划分多个主机在不同集群里，集群中从节点容许有限失效，主-从群均为同构，集群需支持负载均衡，物理资源首先可以分割成许多物理交付点，每个物理交付点可以有多个集群，而逻辑交付点也因不同用户的设计而可以有多个，逻辑交付点提供随需操作系统的服务，在主机上迅速部署虚拟机，集群拓扑形成物理交付点时，将物理的集群分割成几个物理交付点或单个物理交付点，集群拓扑形成逻辑交付点时，若基于原有的单个物理集群，逻辑交付点仅限于单个集群，若基于多个集群则无上述限制。此二选择作为配置选项提供给用户，仅共享空间的逻辑交付点不会将物理服务器虚拟化，以确保计算的高质量和系统的性能，随需操作系统的逻辑交付点虚拟化物理服务器，以提供更多元化的开发/测试设备，此二选择作为配置选项提供给用户，逻辑交付点面向应用时，连接到业务交付平台的每个逻辑交付点均带有版本号，并使用业务交付平台的存储系统来实现存放和恢复，逻辑交付点面向软件化服务器时，使用拉调度来实现对后台资源的承诺，以避免网络流量爆发。

以上结合附图对本发明的自主虚拟网络系统之结构及实现方法的基本流程进行了说明。自主虚拟网络系统仅是本发明在特定场合的一个实施。它充分证明了本发明的实用性。而本发明的具体实现也可以应用于其它非虚拟网络管理的应用系统，例如企业ERP应用系统、遥感器物联网（Machine-to-Machine）应用系统。因而，自主管理使用在自主虚拟网络系统的某些细节不应构成对本发明的限定，本发明将以所附权利要求书界定的范围作为本发明的保护范围。

Claims

1.一种设计和构造多循环自主管理者的系统，包括设计装置和构造装置，其中：

2.一种多循环自主管理者的实现方法，包括：

3.根据权利要求2所述的多循环自主管理者的实现方法，其特征在于，所述自主管理者通过事件驱动方法实现，所述复杂事件处理引擎的每个实例是一个事件处理代理，所述自主管理者是由四个事件处理代理连接而成，由所述事件处理代理来构建的所述自主管理者在分析和规划这两部分中间增加了至少一个额外的循环，所述自主管理者是对经典的自主元素模型中的自主管理者的一种扩展。

4.根据权利要求3所述的多循环自主管理者的实现方法，其特征在于:

所述多循环自主管理者保存、搜索事件处理代理规则库里的规则，保存过去的经验，并自动学习得到新规则；

5.根据权利要求3所述的多循环自主管理者的实现方法，其特征在于，所述混合式自主计算参考架构包括底层、中间层和顶层，其中所述混合式自主计算参考架构的底层包含有虚拟的和物理的网络设备,所述虚拟的和物理的网络设备作为被管资源存在所述混合式自主计算参考架构中,部份被管资源本身就含有自我管理的属性；

6.一种虚拟化的自主管理系统，其特征在于，所述虚拟化的自主管理系统包括：

7.一种具有抢占性权限的接触点系统，所述接触点包括传感器和效应器，运行在操作系统或虚拟机内核，具有内核环０的安全权限，其特征在于：

所述传感器，接收从硬件传来的刺激时，判断可能的故障；

8.一种智能的环0接触点实现方法，其特征在于，所述方法包括：

9.根据权利要求8所述的智能的环0接触点实现方法，其特征在于，所述方法还包括依赖于操作系统平台的方法：

10.一种将硬件资源软件化的服务方法，其特征在于，自主管理者拦截多个并发的请求，将请求映射到一个虚拟有限状态机，并使用虚拟有限状态机计算出物理资源的能力，把能力映射给物理机，最后物理机实现请求。

11.根据权利要求10所述的将硬件资源软件化的服务方法，其特征在于，过程如下：

软件化服务器获得当前状态和行动，并得知能力；

12.一种软件化服务器的实现方法，其特征在于，所述实现方法包括：

13.一种业务交付的虚拟网络系统，其特征在于，所述虚拟网络系统包括六个部分：

14.根据权利要求13所述的业务交付的虚拟网络系统，其特征在于，所述虚拟资源汇聚不同位置、配置的物理资源，实现物理资源类型、部署无关化的资源融合；所述物理资源实现与企业业务划分的数据中心和物理资源网络，支持订阅交付，同时支持按空间分享和按时间分享的物理资源，包括许多未分配和已分配的网络、存储、计算物理资源。

15.一种业务交付虚拟网络系统的自动化方法，其特征在于，所述自动化方法包括：

16.根据权利要求15所述的自动化方法，其特征在于，所述业务交付服务包括：

17.一种自主管理的虚拟网络应用保障系统，其特征在于,所述系统包括：

中央采集控制系统，相当于混合式自主计算参考架构中间层资源管理器;

18.根据权利要求17所述的自主管理的虚拟网络应用保障系统，其特征是，所述性能MAPE服务组件：运行的主机是集群的从机，即网络的叶结点，或是集群的主控主机，即非叶结点，抢占性/关键任务的政策和一般应用的政策均通过网络传输至任何节点；

19.根据权利要求18所述的自主管理的虚拟网络应用保障系统，其特征在于，如果主机实行操作系统虚拟化，

20.一种使用自主管理的网络应用保障系统的实现方法，具有虚拟网络设备自主管理部分，其特征在于：

21.一种自主管理的虚拟网络系统，其特征在于,所述系统包括：

自主管理的硬件交付点装置；

自主管理的软件化服务装置；

22.一种自主管理的虚拟网络系统的实现方法，其特征在于，所述实现方法包括：

基础自主管理实现方法；

虚拟网络实现方法；

23.根据权利要求22所述的自主管理的虚拟网络系统的实现方法，其特征在于，所述会话协议包括：

所述其它虚拟网络协议的荷载内容为：

24.根据权利要求22所述的自主管理的虚拟网络系统的实现方法，其特征在于，所述逻辑交付点服务器为：

25.根据权利要求24所述的自主管理的虚拟网络系统的实现方法，其特征在于，所述逻辑交付点的实现步骤如下：

26.根据权利要求22所述的自主管理的虚拟网络系统的实现方法，其特征在于，

所述业务交付平台接收来自不同用户的请求，如果是网管人员的硬件资源操作请求，则按照简单服务质量规则得出竞争结果，如果是企业业务人员，则进入业务生命周期管理，如果是业务运营人员则进入部署自动化，如果是项目管理经理，则进入订阅服务，由业务服务器的MAPE引擎做多部门、多业务的汇聚，供应业务环境，使项目管理经理做业务设计，如果是与逻辑交付点服务器的交流，则按照MAPE引擎计算的结果向逻辑交付点服务器下达指令，而另一方面，也接收逻辑交付点服务器逻辑资源不足的通知，转告MAPE引擎；

27.根据权利要求22所述的自主管理的虚拟网络系统的实现方法，其特征在于，

所述虚拟网络的集群拓扑划分多个主机在不同集群里，集群中从节点容许有限失效，主-从群均为同构，集群需支持负载均衡，物理资源首先可以分割成许多物理交付点，每个物理交付点可以有多个集群，而逻辑交付点也因不同用户的设计而可以有多个，逻辑交付点提供随需操作系统的服务，在主机上迅速部署虚拟机；

集群拓扑形成物理交付点时，将物理的集群分割成几个物理交付点或单个物理交付点，集群拓扑形成逻辑交付点时，若基于原有的单个物理集群，逻辑交付点仅限于单个集群，若基于多个集群则无上述限制。此二选择作为配置选项提供给用户；

仅共享空间的逻辑交付点不会将物理服务器虚拟化，以确保计算的高质量和系统的性能，随需操作系统的逻辑交付点虚拟化物理服务器，以提供更多元化的开发/测试设备，此二选择作为配置选项提供给用户；

逻辑交付点面向应用时，连接到业务交付平台的每个逻辑交付点均带有版本号，并使用业务交付平台的存储系统来实现存放和恢复，逻辑交付点面向软件化服务器时，使用拉调度来实现对后台资源的承诺，以避免网络流量爆发。