用于替换虚拟机盘的方法和系统的制作方法

文档序号:7778276阅读:3055来源:国知局
用于替换虚拟机盘的方法和系统的制作方法
【专利摘要】至少一个目标虚拟盘描述符与至少一个源虚拟盘描述符合并,该目标虚拟盘描述符描述与目标虚拟化环境中的现有目标虚拟机关联的至少一块虚拟盘,该源虚拟盘描述符描述与源关联的至少一块虚拟盘。执行该合并,以获取和目标虚拟化环境兼容的至少一个合并的虚拟盘描述符。根据至少一个合并的虚拟盘描述符,用与源关联的至少一块虚拟盘来替换与目标虚拟化环境中的现有目标虚拟机关联的至少一块虚拟盘。
【专利说明】用于替换虚拟机盘的方法和系统
【技术领域】
[0001]本发明涉及电、电子和计算机领域且更具体地涉及云计算等。
【背景技术】
[0002]虚拟机(VM)是计算机的一种软件实现,其和物理机一样执行程序。虚拟机可以具有与之关联的一块或多块虚拟盘。

【发明内容】

[0003]本发明的原理提供用于替换虚拟机盘的技术。
[0004]在一个方面,示例性方法包括将至少一个目标虚拟盘描述符与至少一个源虚拟盘描述符进行合并的步骤,该目标虚拟盘描述符描述与目标虚拟化环境中的现有目标虚拟机关联的至少一块虚拟盘,该源虚拟盘描述符描述与源关联的至少一块虚拟盘。执行该合并,以获取和目标虚拟化环境兼容的至少一个合并的虚拟盘描述符。进一步的步骤包括根据至少一个合并的虚拟盘描述符、用与源关联的至少一块虚拟盘来替换与目标虚拟化环境中的现有目标虚拟机关联的至少一块虚拟盘。
[0005]如这里所使用的,“促进”一动作包括执行该动作、使该动作更容易、帮助执行该动作、或使得该动作被执行。于是,作为示例而不是限制,在一个处理器上执行的指令可以通过发送合适的数据或命令使得或帮助动作被执行,促进在远程处理器上执行的指令所执行的动作。为了避免疑问,在操作者通过执行动作之外来促进动作时,该动作仍然是由某个实体或实体组合来执行的。
[0006]本发明的一个或多个实施例或其元素可以以计算机程序产品的形式来实现,该计算机程序产品包括具有用于执行所指出的方法步骤的计算机可用程序代码的计算机可读存储介质。此外,本发明的一个或多个实施例或其元素可以以系统(或装置)的形式来实现,该系统(或装置)包括存储器以及至少一个处理器,该处理器耦合到存储器且可操作地执行示例性方法步骤。另外,在另一方面,本发明或的一个或多个实施例其元素可以以装置的形式来实现,该装置用于实现这里描述的一个或多个方法步骤;该装置可以包括:(i)软件模块,其被存储在计算机可读存储介质(或多个这样的介质)中并且可以在硬件处理器上实现,或者(ii)软件模块或某些硬件模块的组合;以及(i)-(ii)中的任一个实现这里阐述的特定技术。
[0007]本发明的技术可以提供非常有益的技术效果。例如,一个或多个实施例可以提供下列优势中的一个多个:
[0008].提供用与源虚拟机关联的一块或多块虚拟盘来替换与目标虚拟机关联的相同数量的虚拟盘的能力;
[0009].使得托管云(managed cloud)等能够导入现有的虚拟机和/或虚拟机映像;
[0010].使虚拟机能恢复到之前的状态。
[0011]根据将结合附图阅读的本发明的说明性实施例的下列详细描述,本发明的其他特征和优势将变得明显。
【专利附图】

【附图说明】
[0012]图1示出了根据本发明的实施例的云计算节点;
[0013]图2示出了根据本发明的实施例的云计算环境;
[0014]图3示出了根据本发明的实施例的抽象模型层;
[0015]图4示出了根据本发明的方面的高阶流程图;
[0016]图5示出了根据本发明的方面的详细流程和框图;
[0017]图6示出了根据本发明的方面的示例性系统框图;
[0018]图7示出了根据本发明的方面的示例性系统图,其包含重要阶段的系统状态;
[0019]图8示出了根据本发明的方面的在源环境中并且迁移到云之后的当前服务器;
[0020]图9和10示出了图8的服务的替代迁移方法;
[0021]图11示出了根据本发明的方面的示例性供应流程;
[0022]图12示出了根据本发明的实施例的实例捕获;
[0023]图13示出了根据本发明的实施例的采用和调整过程;
[0024]图14示出了根据本发明的实施例的“创建服务器”弹出的示例性屏幕视图;
[0025]图15示出了根据本发明的方面的供应流程中的调整的示例性概览;
[0026]图16示出了根据本发明的方面的组合流程图和框图;
[0027]图17示出了根据本发明的一个或多个方面的要被迁移到目标环境的源环境;
[0028]图18示出了根据本发明的一个或多个方面的图5中的源环境可迁移至的目标环境;
[0029]图19示出了根据本发明的一个或多个方面的用于云迁移的管理基础架构分析中的示例性阶段;
[0030]图20示出了根据本发明的一个或多个方面的示例性用户界面;
[0031]图21示出了根据本发明的一个或多个方面的用于服务器的小子集的非限制示例性结果;
[0032]图22示出了根据本发明的方面的示例性系统框图;
[0033]图23示出了根据本发明的方面的示例性快照管理器;
[0034]图24示出了根据本发明的方面的基于虚拟映像库的示例性实现;
[0035]图25示出了根据本发明的方面的示例性回滚至长期快照;
[0036]图26是根据本发明的方面的流程图,示出了计算在迁移期间对映像做出的确切改变的步骤;
[0037]图27是根据本发明的方面的示例性过程流;并且
[0038]图28是根据本发明的方面的快照管理系统的示例性软件架构图;
[0039]图29示出了根据本发明的方面的示例性系统图;
[0040]图30示出了根据本发明的示例性方法;
[0041]图31示出了根据本发明的方面的示例性“交换”流程图;
[0042]图32示出了根据本发明的方面的示例性“合并虚拟资源描述符”流程图;
[0043]图33示出根据本发明的方面的另一示例性系统图;[0044]图34示出了虚拟机映像和实例的相关方面;
[0045]图35示出了根据本发明的方面的虚拟机资源描述符的第一实施例;
[0046]图36示出了根据本发明的方面的虚拟机资源描述符的第二实施例;
[0047]图37是根据本发明的方面的用于更新目标虚拟机描述符的示例性方法步骤的流程图;
[0048]图38是根据本发明的方面的示例性预备方法步骤的流程图;
[0049]图39是根据本发明的方面的示例性软件架构图;
[0050]图40示出了根据本发明的方面的标准化框架;
[0051]图41示出了根据本发明的方面的样本离线调整的流程;
[0052]图42示出了根据本发明的方面的示例性流程图;
[0053]图43示出了根据本发明的方面的示例性标准化架构;
[0054]图44-46示出了根据本发明的方面的示例性调整阶段;
[0055]图47示出了根据本发明的方面的示例性架构。
【具体实施方式】
[0056]云计算是一种服务交付模式,用于对共享的可配置计算资源池进行方便、按需的网络访问。可配置计算资源是能够以最小的管理成本或与服务提供者进行最少的交互就能快速部署和释放的资源,例如可以是网络、网络带宽、服务器、处理、内存、存储、应用、虚拟机和服务。这种云模式可以包括至少五个特征、至少三个服务模型和至少四个部署模型。
[0057]特征包括:
[0058]按需自助式服务:云的消费者在无需与服务提供者进行人为交互的情况下能够单方面自动地按需部署诸如服务器时间和网络存储等的计算能力。
[0059]广泛的网络接入:计算能力可以通过标准机制在网络上获取,这种标准机制促进了通过不同种类的瘦客户机平台或厚客户机平台(例如移动电话、膝上型电脑、个人数字助理PDA)对云的使用。
[0060]资源池:提供者的计算资源被归入资源池并通过多租户模式服务于多重消费者,其中按需将不同的实体资源和虚拟资源动态地分配和再分配。一般情况下,消费者不能控制或甚至并不知晓所提供的资源的确切位置,但可以在较高抽象程度上指定位置(例如国家、州或数据中心),因此具有位置无关性。
[0061]迅速弹性:能够迅速、有弹性地(有时是自动地)部署计算能力,以实现快速扩展,并且能迅速释放来快速缩小。在消费者看来,用于部署的可用计算能力往往显得是无限的,并能在任意时候都能获取任意数量的计算能力。
[0062]可测量的服务:云系统通过利用适于服务类型(例如存储、处理、带宽和活跃用户帐号)的某种抽象程度的计量能力,自动地控制和优化资源效用。可以监测、控制和报告资源使用情况,为服务提供者和消费者双方提供透明度。
[0063]服务模型如下:
[0064]软件即服务(SaaS):向消费者提供的能力是使用提供者在云基础架构上运行的应用。可以通过诸如网络浏览器的瘦客户机接口(例如基于网络的电子邮件)从各种客户机装置访问应用。除了有限的特定于用户的应用配置设置外,消费者既不管理也不控制包括网络、服务器、操作系统、存储、乃至单个应用能力等的底层云基础架构。
[0065]平台即服务(PaaS):向消费者提供的能力是在云基础架构上部署消费者创建或获得的应用,这些应用利用提供者支持的程序设计语言和工具创建。消费者既不管理也不控制包括网络、服务器、操作系统或存储的底层云基础架构,但对其部署的应用具有控制权,对应用管理环境配置可能也具有控制权。
[0066]基础架构即服务(IaaS):向消费者提供的能力是消费者能够在其中部署并运行包括操作系统和应用的任意软件的处理、存储、网络和其他基础计算资源。消费者既不管理也不控制底层的云基础架构,但是对操作系统、存储和其部署的应用具有控制权,对选择的网络组件(例如主机防火墙)可能具有有限的控制权。
[0067]部署模型如下:
[0068]私有云:云基础架构单独为某个组织运行。云基础架构可以由该组织或第三方管理并且可以存在于该组织内部或外部。
[0069]共同体云:云基础架构被若干组织共享并支持有共同利害关系(例如任务使命、安全要求、政策和合规考虑)的特定共同体。共同体云可以由共同体内的多个组织或第三方管理并且可以存在于该共同体内部或外部。
[0070]公共云:云基础架构向公众或大型产业群提供并由出售云服务的组织拥有。
[0071]混合云:云基础架构由两个或更多部署模型的云(私有云、共同体云或公共云)组成,这些云依然是独特的实体,但是通过使数据和应用能够移植的标准化技术或私有技术(例如用于云之间的负载平衡的云突发流量分担技术)绑定在一起。
[0072]云计算环境是面向服务的,特点集中在无状态性、低耦合性、模块性和语意的互操作性。云计算的核心是包含互连节点网络的基础架构。
[0073]现在参考图1,其中显示了云计算节点的一个例子。图1显示的云计算节点10仅仅是适合的云计算节点的一个示例,不应对本发明实施例的功能和使用范围带来任何限制。总之,云计算节点10能够被用来实现和/或执行在此所述的任何功能。
[0074]云计算节点10具有计算机系统/服务器12,其可与众多其它通用或专用计算系统环境或配置一起操作。众所周知,适于与计算机系统/服务器12 —起操作的计算系统、环境和/或配置的例子包括但不限于:个人计算机系统、服务器计算机系统、瘦客户机、厚客户机、手持或膝上装置、基于微处理器的系统、机顶盒、可编程消费电子产品、网络个人电脑、小型计算机系统、大型计算机系统和包括上述任意系统的分布式云计算技术环境,等
坐寸ο
[0075]计算机系统/服务器12可以在由计算机系统执行的计算机系统可执行指令(诸如程序模块)的一般语境下描述。通常,程序模块可以包括执行特定的任务或者实现特定的抽象数据类型的例程、程序、目标程序、组件、逻辑、数据结构等。计算机系统/服务器12可以在通过通信网络链接的远程处理装置执行任务的分布式云计算环境中实施。在分布式云计算环境中,程序模块可以位于包括存储装置的本地或远程计算系统存储介质上。
[0076]如图1所示,云计算节点10中的计算机系统/服务器12以通用计算装置的形式表现。计算机系统/服务器12的组件可以包括但不限于:一个或者多个处理器或者处理单元16,系统存储器28,连接不同系统组件(包括系统存储器28和处理单元16)的总线18。
[0077]总线18表示几类总线结构中的一种或多种,包括存储器总线或者存储器控制器,外围总线,图形加速端口,处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说,这些体系结构包括但不限于工业标准体系结构(ISA)总线,微通道体系结构(MAC)总线,增强型ISA总线、视频电子标准协会(VESA)局域总线以及外围组件互连(PCI)总线。
[0078]计算机系统/服务器12典型地包括多种计算机系统可读介质。这些介质可以是能够被计算机系统/服务器12访问的任意可获得的介质,包括易失性和非易失性介质,可移动的和不可移动的介质。
[0079]系统存储器28可以包括易失性存储器形式的计算机系统可读介质,例如随机存取存储器(RAM)30和/或高速缓存存储器32。计算机系统/服务器12可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例,存储系统34可以用于读写不可移动的、非易失性磁介质(图1未显示,通常称为“硬盘驱动器”)。尽管图1中未示出,可以提供用于对可移动非易失性盘(例如“软盘”)读写的盘驱动器,以及对可移动非易失性光盘(例如⑶-ROM,DVD-ROM或者其它光介质)读写的光盘驱动器。在这些情况下,每个驱动器可以通过一个或者多个数据介质接口与总线18相连。存储器28可以包括至少一个程序产品,该程序产品具有一组(例如至少一个)程序模块,这些程序模块被配置以执行本发明各实施例的功能。
[0080]具有一组(至少一个)程序模块42的程序/实用工具40,可以存储在存储器28中,这样的程序模块42包括但不限于操作系统、一个或者多个应用程序、其它程序模块以及程序数据,这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块42通常执行本发明所描述的实施例中的功能和/或方法。
[0081]计算机系统/服务器12也可以与一个或多个外部装置14 (例如键盘、指向装置、显示器24等)通信,还可与一个或者多个使得用户能与该计算机系统/服务器12交互的装置通信,和/或与使得该计算机系统/服务器12能与一个或多个其它计算装置进行通信的任何装置(例如网卡,调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口 22进行。并且,计算机系统/服务器12还可以通过网络适配器20与一个或者多个网络(例如局域网(LAN),广域网(WAN)和/或公共网络,例如因特网)通信。如图所示,网络适配器20通过总线18与计算机系统/服务器12的其它模块通信。应当明白,尽管图中未示出,其它硬件和/或软件模块可以与计算机系统/服务器12—起操作,包括但不限于:微代码、装置驱动器、冗余处理单元、外部盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。
[0082]现在参考图2,其中显示了示例性的云计算环境50。如图所示,云计算环境50包括云计算消费者使用的本地计算装置可以与其相通信的一个或者多个云计算节点10,本地计算装置例如可以是个人数字助理(PDA)或移动电话54A,台式电脑54B、笔记本电脑54C和/或汽车计算机系统54N。云计算节点10之间可以相互通信。可以在包括但不限于如上所述的私有云、共同体云、公共云或混合云或者它们的组合的一个或者多个网络中将云计算节点10进行物理或虚拟分组(图中未显示)。这样,云的消费者无需在本地计算装置上维护资源就能请求云计算环境50提供的基础架构即服务(IaaS)、平台即服务(PaaS)和/或软件即服务(SaaS)。应当理解,图2显示的各类计算装置54A-N仅仅是示意性的,云计算节点10以及云计算环境50可以与任意类型网络上和/或网络可寻址连接的任意类型的计算装置(例如使用网络浏览器)通信。
[0083]现在参考图3,其中显示了云计算环境50 (图2)提供的一组功能抽象层。首先应当理解,图3所示的组件、层以及功能都仅仅是示意性的,本发明的实施例不限于此。如图3所示,提供下列层和对应功能:
[0084]硬件和软件层60包括硬件和软件组件。硬件组件的例子包括:主机,例如IBM? zSeries⑧系统;基于Rise (精简指令集计算机)体系结构的服务器,例如
IBM pSeries? 系统;ibm xSeries? 系统;IBM BladeCenter? 系统;存储装置;网络和
网络组件。软件组件的例子包括:网络应用服务器软件,例如ibm WebSphere?应用服务器软件;数据库软件,例如IBM DB2?数据库软件。(IBM, zSeries, pSeries, xSeries, BIadeCenter, WebSphere以及DB2是国际商业机器公司在全世界各地的注册商标)。
[0085]虚拟层62提供一个抽象层,该层可以提供下列虚拟实体的例子:虚拟服务器、虚拟存储、虚拟网络(包括虚拟私有网络)、虚拟应用和操作系统,以及虚拟客户端。
[0086]在一个示例中,管理层64可以提供下述功能:资源供应功能:提供用于在云计算环境中执行任务的计算资源和其它资源的动态获取;计量和定价功能:在云计算环境内对资源的使用进行成本跟踪,并为此提供帐单和发票。在一个例子中,该资源可以包括应用软件许可。安全功能:为云的消费者和任务提供身份认证,为数据和其它资源提供保护。用户门户功能:为消费者和系统管理员提供对云计算环境的访问。服务水平管理功能:提供云计算资源的分配和 管理,以满足必需的服务水平。服务水平协议(SLA)计划和履行功能--为根据SLA预测的对云计算资源未来需求提供预先安排和供应。
[0087]工作负载层66提供云计算环境可能实现的功能的示例。在该层中,可提供的工作负载或功能的示例包括:地图绘制与导航;软件开发及生命周期管理;虚拟教室的教学提供;数据分析处理;交易处理;以及移动桌面。
[0088]讦移到托管云
[0089]硬件基础架构即服务(HIaaS)云提供基本(bare-bone)虚拟机作为服务。它还可以提供操作系统(OS)甚至软件,但典型地不会为OS或软件提供支持。托管基础机构即服务(MIaaS)云提供全服务的虚拟机。服务例如可以包括OS补丁并支持OS的安全性和合规性。MIaaS的一个显著方面是通过下列方式实现更简单的管理:标准化为特定的一组目录映像,实例从该组映像生成;在部署期间将这些实例自动链接到管理工具;以及/或不给客户OS级别的管理权限,从而实例上的操作系统保持为云管理员配置它们的样子。
[0090]MIaaS云不会自然地具有外部实例的导入或注册特征,因为MIaaS的一个显著方面是通过下列方式实现更简单的管理:标准化为特定的一组目录映像,实例从该组映像生成;在部署期间将这些实例自动链接到管理工具;以及,典型地,不给客户OS级别的管理权限,从而实例上的操作系统可保持为云管理员配置它们的样子。因此,在迁移到MIaaS云时,简单地使用源实例上的P2V (物理到虚拟)转换,或直接地复制已经虚拟化的实例,然后期望它们在云管理程序(cloud hypervisor)上运行,通常是不可行的。这是因为它们将无法满足上述标准(通过所述标准更简单的管理在MIaaS云中实现),因此它们对于MIaaS云的管理来说是不可接受的。
[0091]此外,关于MIaaS云,标准注册(即使得新实例为通用IaaS云管理系统以及MIaaS云的特定管理系统所知)典型地被内置于从目录映像的供应(provisioning)中。有利地,一个或多个实施例提供了新的注册过程,其中,外部实例可被包含在到MIaaS云的迁移中。确实,一个或多个实施例有利地提供了一种系统和方法,用于快速地迁移到MIaaS (且更一般地,IaaS)云。该方法包括实例以映像形式传送至云;(运行中或映像形式的)实例调整为云标准;以及实例注册到云OSS和BSS系统(运行和业务支持系统)中。可选的附加步骤解决之前的分析、测试和处理失败,以及/或开始和结束改变窗口以及实际停机时间,以最小化风险和运行中断。
[0092]一个或多个实施例有利地提供了一种系统化(以及甚至自动化)的将客户实例快速地迁移到MIaaS云中的方法,其不涉及重新安装过程。一个或多个实施例可用于MIaaS云迁移,并且能够进行物理到虚拟风格的实例导入。
[0093]一个或多个实施例提升了对基础架构自身以及该基础架构的管理两者进行标准化的能力。相信这样的标准化将转而允许降低IT运行成本并允许进一步的自动化。一个或多个实施例提供了一种迁移到MIaaS云的技术,它比需要重新安装的技术要便宜地多。
[0094]如上所述,一个或多个实施例提供了一种迁移技术,其具有下列一种或多种优势:
[0095].显著的覆盖率(可以使用该方法的实例以及因而工作负载的百分比,),
[0096]?低成本,其特别受到所需的手动工作的限制(特别是与重新安装方法相比较),
[0097].短的迁移时间(因为改变窗口 /允许的运行中断典型地较短),
[0098].低风险(例如,应用运行中断超过计划的风险),以及/或
[0099]?可预测性(即,针对该迁移技术选择的工作负载将很可能获得成功)。
[0100]现在注意图4, 从想要迁移的现有客户环境(见图5)中的实例401开始。在步骤404中,将实例以映像形式传送至云。如果这不成功,保留原来的客户版本401并重新计划迁移;例如,将它保留在原来的环境中,或者执行经典的迁移至服务提供者环境,其中它可以保持为物理实例,或者可以对实例进行显著的改变从而它变为可虚拟化。另一方面,如果步骤404成功,在步骤406中,实现对(运行中和/或映像形式的)实例的调整,以确保它符合云标准。如果这不成功,保留原来的客户版本401并重新计划迁移;例如,在没有云标准的客户环境或服务提供者环境中或者在HIaaS云中将它虚拟化,或者执行更为复杂的重新安装迁移,其中,单独的软件组件被重新安装,并且客户数据被单独地而不是在整个映像中传送。另一方面,如果步骤406成功,在步骤408中,执行实例在云OSS和BSS系统中的注册。如果步骤408不成功,保留原来的客户版本401并重新计划迁移;例如,通过与步骤404或406失败时相同的方法。另一方面,如果步骤408成功,结果是成功地迁移到MIaaS
410。
[0101]注意到云注册的开始的子步骤可在调整之前发生或者可以与调整交错地发生。但是,从逻辑的角度来看,最终注册(即导入的实例作为云托管实例的最终接受)应该在调整结束之后。
[0102]转到图5,更详细地描述非限制的示例性方法。客户环境402通过广域网(WAN)514等连接到MIaaS云环境410。开始,执行发现过程518,来确定物理520和虚拟522实例两者以及它们在客户环境402中的配置。在步骤524中执行分析和计划。如果结果是不利的,则寻求其他的方法,例如物理到物理(P2P)迁移、应用重新安装、遗留系统的保持等,如图526所示。此外,如果步骤518、524中的任一个表明需要小的修复(即对实例的小改变,以使它们与云兼容),在步骤516执行相同的步骤,且过程流程回到步骤518。另一方面,如果步骤524表明使用这里公开的一种或多种技术的迁移是可行的,流程进入步骤528中的基线测试和备份。在步骤528中,如530所示,运行一组测试例来证明源系统满足需要在目标环境中保持的标准,例如,在其所有功能测试例或性能要求下仍然测试正确。这么做是为了确保在迁移过程之前修复已经存在的任何错误。此外,如图532所示,执行备份过程,以允许在迁移过程中遇到任何问题时能恢复。优选地,在完成备份532之前,物理或虚拟实例520或522上的应用被停止,从而在改变将不会被复制到MIaaS云环境的条件下客户环境中不会有进一步的改变。处理然后进入步骤534,其中,要迁移的实例被捕获。一个或多个说明性实施例集中于迁移至MIaaS云的特定方面,这主要是按每个实例进行的。置于整体迁移,典型地在多个实例的波中执行,每个波例如在每个周末尝试保持工作负载或者交互实例在一个波中。在Athey等在2011年9月I日的美国专利申请公开20110213883“Systemand method for object migration using waves”(使用波的对象迁移的系统和方法)以及Devarakonda 等在 2012 年 5 月 3 日的美国专利申请公开 20120109844“Total cost-basedmigration waves planning”(基于总成本的迁移波计划)中公开了这样的方面,所述专利申请公开的全部内容为所有目的通过引用显式地结合于此。
[0103]在536可见,该实例捕获步骤可以同时包括例如具有一种或多种合适工具的物理到虚拟(P2V)和虚拟到虚拟(V2V)技术。合适工具的一个非限制示例是PlateSpin?
Migrate, 一种用于快速和高效的P2V (更广义地,任何地方到任何地方)迁移的物理/虚拟转换工具;该工具可以从美国德克萨斯州休斯顿的NetIQ公司获得;另一种是VMwarevCenter Converter,其可以从美国加利福尼亚州Palo Alto的VMware公司获得。在一个或多个非限制的示例性实施例中,步骤534的最终结果是虚拟机盘格式(VMDK)文件。
[0104]需要强调,这里提到了很多产品名称;这些仅作为给技术人员的示例,并传达发明人对最佳实施方式的理解。它们不是要限制权利要求,除非在权利要求中显式地说明,而被
认为是相应一般软件产品的示例;例如,PlateSpin? Migrate广泛地代表物理/虚拟转
换工具。
[0105]如步骤538所示,捕获的实例然后通过网络514传输到云位置410。启动盘外部的数据544可以从上述vmdk文件单独地传输(见542),特别是如果它较大并且数据传输可以更早开始的话。如540所示,通过使用合适的工具来控制传送,实例和数据通过网络514来传输。这样的工具的非限制的例子包括上述PLATESPIN工具以及用于数据的Softek透明
数据迁移设施(TDMF? )工具(美国纽约州Armonk的国际商业机器公司的注册商标)。
数据544典型地不受MIaaS云的特殊方面的影响,S卩,它可被迁移并且通过一般的方式链接回到vmdk。为了避免混乱,图中忽略了关于数据544的更多细节。
[0106]在步骤546中,对传输的实例554进行功能测试,该实例是从云管理程序上的映像重启的。如547所示,这可以包括例如执行测试例的集合或子集;在调整之间这可以被重复若干次。同时,需要注意,在起初到达云环境410时,传输的实例位于MIaaS云着陆区(landing zone)中。如果此时功能测试成功,处理流程进行到实例调整和采用556。这是修改实例的重要步骤,因此它可以在标准的MIaaS环境中运行。在所有调整之后,并且可能在特定的调整步骤之间,功能测试被重复,如从步骤556到546的逆向箭头所示。在每个成功的功能测试之后,如步骤550所示实例可被备份(即可以取实例的快照552)(例如,作为高效实例库552中的vmdk文件)以用于以后的引用,作为实例的最近的看起来正确的状态。如果在所有调整556之后功能测试成功,在MIaaS云生产区域574中的云管理程序558上对传输的实例进行实例化。另一方面,如果在其重复的某一次中功能测试不成功,处理流程进行到修复步骤548。修复过程可以通过若干种途径来进行。典型地,错误消息将被分析并与最近的改变关联。在功能测试546第一次执行时,这些最近的改变是虚拟化和新的管理程序。在后续执行中,它们是自前一次执行功能以来的调整所做的改变。为此,引用在这些最后的改变之前的实例的快照552是有用的。如果这些错误的修复不成功(这可以通过重新运行功能测试来确定),流程回到步骤528,即该实例的迁移(至少在该时刻)停止,并且用备份来恢复客户环境402中的源实例520或522。当修复成功时,处理前进,就好像该功能测试立即成功,即进行第一次或下一次调整,或者在已完成所有调整的情况下,在MIaaS云生产区域574中的云管理程序558上对实例进行实例化。
[0107]在实例调整和采用步骤556中,管理程序554上的实例被调整为云交付标准并被采用到云BSS和0SS,如568所示。如570所示,该过程使用调整子流所扩展的供应流程。例如,MIaaS的标准供应流程(B卩,用于从云目录选择而不是迁移的实例)可以在资产管理系统、监控系统中注册新实例,并为其开始记账(accounting)和记费(billing)。可以从标准供应流程重用该功能。另一方面,标准供应流程可以不安装在普通实例上MIaaS云所需的特定监控代理,因为它们将被预安装在云目录映像中。因此,安装该代理将是特殊的调整流程的一部分。类似地,对云目录映像所具有的级别的安全补丁的更新可以是调整流程中的额外步骤。当所有调整步骤之后的功能测试最终已成功完成时,如所述的,在生产区域574的云管理程序558上发生实例化。
[0108]在一个或多个实施例中,着陆区域是为了迁移到MIaaS而添加的特殊区域,因为在MIaaS云环境(见项目554)的管理程序上第一次启动实例以进行测试和调整时,它们还没有满足云标准,且因此普通的云管理不能处理它们。它们也不会满足安全云中的OS管理所提供并假设的安全标准。为此,可以至少通过使用不同的服务器来容纳(host)管理程序以从物理上分离着陆区域572和生产区域574,并且通过防火墙来将它们进行分离,如这两个区域之间的两个箭头所示该防火墙仅允许受控制的信息通过。此外,存储系统可以是分离的。物理分离的另一个好处是,云管理系统(例如容量和性能管理)于是不需要处理管理程序,该管理程序部分具有正常的托管的云实例,而部分具有还不可管理的导入实例。但是,也可以使用逻辑分离,即,信任云管理程序不会让可能不安全的导入映像影响其他映像,并将云管理系统扩展为处理被分区的管理程序。
[0109]一旦在生产区域574中的云管理程序558上实例化相关的迁移的实例,例如可以进行用户接受测试560,以验证性能相当于基线。如果不是这样,在562进行修复,以校正管理程序558上的实例。如果合适,该修复过程可以利用实例库552或替代技术526 ;如果这发生,可以从生产区域574再次移除实例,直到它被修复。用户接受测试560中的测试例优选地应与基线测试中的测试例相同。如果用户相关的功能由多个实例(例如web服务器、应用服务器和数据库)来执行,它们通常一起覆盖多个实例。相反,功能测试可以仅针对每个实例。当测试560成功时,在步骤564中执行切换(cut-over),并考虑任何客户域名服务器(DNS)改变,等等,如565中所示。在完成切换时,如566所示,迁移的实例以照常运行(business as usual, BAU)的方式在MIaaS云生产区域中运行。[0110]在图5中,可以理解,在一个或多个示例性实施例中,步骤516、528和560是在客户的范围内而步骤518、524、526、434、538、550、556和564是在云服务提供者的范围内。步骤546、548和562具有双方之间的混合的性质。
[0111]图6示出了示例性系统图。客户环境402包括一个或多个源实例684 (对应于图5中的初始物理或虚拟实例520和522)以及传送代理682。网络514提供客户环境402和MIaaS云环境410之间的连接。环境410包括着陆区域572、生产区域574和管理区域680。传送的实例686位于着陆区域572中(元素554表示在管理程序上运行的实例)。最终的目标实例668位于生产区域574中(元素558表示在管理程序上运行的实例)。云管理区域680包括多个管理组件。传送核心组件690与传送代理682结合工作,执行源实例684到传送实例686的实例传送。调整组件692协调关于图5中的着陆区域572讨论的调整过程。注册组件694将调整的实例注册到MIaaS云的正常管理系统,这里由BSS和0SS696、698来表示。如568所示,云OSS和BSS系统(运行和业务支持系统)698、696为步骤556提供输入。MIaaS云中的OSS和BSS的正常功能是管理生产区域574中的实例。但是,着陆区域572还至少需要最小的0SS,例如用于容量管理且由此在源实例684进入时找到合适的位置(具有足够容量的服务器和存储)。如果着陆区域与生产区域物理分离,则在更详细的级别上,OSS也可被分离。在任何情形下,调整组件692和注册组件694准备实例以被接收到0SS698中,因此,在它们需要与OSS需求相关的知识这一点上,至少存在抽象的连接。典型地不需要用于着陆区域的BSS,因为在着陆区域中,实例受到迁移过程的控制,并且对于客户或端用户还不可见。
[0112]图7示出了在重要的时刻(即在重要的阶段)的系统状态;即初始状态707、在传输709之后、以及在切换(云BAU) 711之后。在状态707中,客户的现有管理工具703管理客户环境402中的物理实例520和虚拟522实例两者。所述实例被存储在存储705中(例如,关于备份步骤528和532所述的,但还有实例的普通外部存储,如果它是在服务器外部(例如在存储区域网络中或者在网络文件系统中)的话)。实例被捕获。如以上关于536所讨论的,该实例捕获可以包括例如使用一种或多种合适工具的物理到虚拟(P2V)和虚拟到虚拟(V2V)技术两者;传输可以经过WAN514 (这可以包括例如最终的虚拟专用网络(VPN)(在迁移完成之后的正常运行期间用于客户和云环境之间的通信)或者临时线路)或通过物理介质的传送。在一个实施例中,云环境410包括云着陆区域572中的云提供者硬件和管理程序554、云生产区域中的云提供者硬件和管理程序558、以及共享存储701。该实施例是如上所述的着陆区域和生产区域的完全物理分离和仅逻辑分离之间的折中,在前一情形下,甚至存储也是分离的,在后一情形下,甚至管理程序也会被共享并且区域分离将通过管理程序来实施,这两者都在可能的实施例中。该混合实施例的一个好处是,从着陆区域到生产区域的最终传送不需要复制数据;只是将属于该实例的存储卷的所有权变更为生产区域。
[0113]在传输之后,如709所示,在着陆区域572中的云提供者硬件和管理程序554上物理和虚拟实例520、522现在都已被虚拟化,分别如720、722所示,并且在此进行调整和测试。迁移的数据被存储在共享区域701中。优选地,源实例520、522在传送之前已被关闭,如以上关于备份528所解释的。一种极端的情形是,它们根本不在运行(对于520,物理服务器被关闭;对于522,从管理程序移除实例),但典型地只会停止它们上面的服务(从而不会进行在云生产区域中恢复照常运行时会丢失的改变)。如果可区分只读服务,例如,在信息网页上浏览,这些可保持运行。此外,在迁移失败时典型地仍会在客户管理工具中保持实例520和522,从而可以快速恢复客户环境中的运行。
[0114]在切换之后,在云BAU (照常运行)状态下,如711所示,客户环境711中的物理、虚拟和存储资源520、522被关闭,并且它们使用的存储705被释放。同时,如关于图5所述的,任何需要的调整和修复都已完成,分别如724、72所示,在云生产区域中的云提供者硬件和管理程序558上物理和虚拟实例520、522两者都已被虚拟化。在着陆区域和生产区域的部分物理分离的该实施例中,迁移的数据仍被存储在共享存储701中。使用完全的物理分离,将会有两个不同的存储系统,一个在着陆区域中且一个在生产区域中,并且数据在阶段709位于前者上而在阶段711位于后者上。BAU云处理在568所示的OSS和BSS系统(运行和业务支持系统)698、696的控制下发生。可以向客户管理工具703提供与生产区域574的接口。但是,这典型地仅涉及在应用层上进行管理的那些特定工具,而执行OS级别功能的工具(例如OS性能管理)已被568中的云OSS替代。例如,实例(开始是520或522,然后是720或722,最后是724或726)可以包含数据库,且用户可以具有数据库管理工具作为703的一部分。MIaaS云(与PaaS云相反)典型地不会执行数据库管理。因此,客户数据库管理工具获取到实例724或726上的该数据库的链接。该方法使用云的客户链接到其在云上的实例的正常方式,例如VPN ;这与MIaaS云的任何分区或管理限制不会冲突。需要注意,图7示出了一个小时到两天的示例性时间以从初始状态707移到“传输后”状态709,以及从两个小时到一天的示例时间以从“传输后”状态709移到“切换云BAU之后”的状态711。这些值旨在为技术人员提供有益的例子但不是要限制。
[0115]一个或多个实施例由此提供了一种将实例迁移到云中的方法,包括将实例以映像形式传送到云;将实例调整为云标准;以及将实例注册到云管理系统中。在某些情形下,由云供应方法的变体来执行注册,在该变体中,以选取传送的实例来代替选取目录映像。在某些实施例中,云管理系统包括运行支持系统和业务支持系统。在某些实施例中,云标准包括一个或多个安全标准、基础架构标准、补丁管理标准和基础架构管理工具标准。
[0116]此外,在一个或多个实施例中,通过工作流引擎中定义的工作流来进行调整。在某些情形下,通过特殊的工具(例如补丁管理工具)在工作流中进行一次或多次调整。
[0117]在某些实施例中,在传送步骤之前,对实例进行分析以确定它是否适合云和给定的迁移方法,且以后仅考虑合适的实例。此外,在某些实施例中,在传输之前、传输之后、不同的调整之间、调整之后以及迁移之后的一个或多个时间进行测试,并且如果一次或多次测试失败则进行修复和/或回退。在某些情形下,在一次或多次迁移决策(即在本段的前面提到的是否适合云)和/或测试及回退决策中将多个实例当成整体。
[0118]此外,一个或多个实施例包括发现、失败的实际处理、开始和结束改变窗口和实际的停机时间、调整和注册的详细交错以及/或切换步骤。
[0119]现在将定义这里使用的特定术语:
[0120]IaaS云:基础架构即服务是云的普通术语,主要为其用户提供虚拟机(VM),而不是还提供VM上的软件(被称为PaaS,平台即服务)或提供软件而不访问VM (被称为软件即服务)或业务过程(BPaaS )。
[0121]这里给出了 IaaS云的以下细分:
[0122]HIaaS云:硬件基础架构即服务(HIaaS)云提供基本虚拟机作为服务。它还可以提供操作系统(OS)甚至软件,但典型地不会为OS或软件提供支持(例如,可以从美国华盛顿州西雅图的亚马逊网络服务有限责任公司获得的亚马逊弹性计算云(Amazon EC2))。
[0123]MIaaS:托管基础架构即服务云提供全服务的虚拟机。服务例如可以包括OS补丁和对OS的安全性和合规性的支持(例如,可以从美国纽约州Armonk的国际商业机器公司获得的云环境 IBM SmartCloud Enterprise+,也被称为 IBM SCE+)。
[0124]实例:操作系统实例以及在该操作系统上运行的所有软件。它可以是物理的(即直接在服务器上运行)或虚拟的(即已经在管理程序上运行)。
[0125]源实例:迁移之前在源端运行的实例。
[0126]映像:实例的文件表示。
[0127]目录映像:云目录中的映像,如果在云中从头开始而不是通过快速迁移来创建新实例,则该映像被使用。
[0128]供应:这是订购IaaS中的VM实例的标准方法一用户从目录订购VM,且相应的实际映像被实例化为运行的实例。
[0129]重新安装迁移:从MIaaS云的角度来看,将应用移动到该云的标准方式是首先提供目录映像,然后在其中重新安装必要的软件组件、源代码、配置和数据。但是,这典型地是非常耗时和昂贵的过程。
[0130]基于映像的迁移:基于映像的迁移使用客户实例来将应用迁移到云。在经典的虚拟化中,基于映像的迁 移是一个标准(P2V)且可以非常快。但是,由于从源实例直接产生的映像不能实现MIaaS云的管理部分,迄今为止,基于映像的迁移对于MIaaS云还不可行。
[0131]快速迁移到MIaaS云:根据一个或多个实施例的基于映像的迁移的一个扩展,其可以在MIaaS云中处理基于映像的迁移的挑战。
[0132]现在参考图8,关于快速迁移,技术人员将理解,在服务器802上典型地有很多事物;例如,中间件或其他现成软件(MW) 804、806 ;基础架构软件(“Infra”)808,例如监控和供应代理;自定义代码810 ;以及/或脚本812,例如用于备份、调度清理任务、数据传送等。当然,服务器包括硬件820和操作系统(OS) 822 (典型地具有注册表和用户(为了避免混乱没有单独编号))。如824所示,当前的服务器可以是具有OS、数据和软件的简单物理服务器,或者已经通过合适的管理程序被虚拟化。中间件例如804、806典型地具有配置814、数据816 (例如数据库)、代码818 (例如SQL脚本),且通常与其他脚本(例如数据库管理员脚本)关联。这些中的大多数不需要位于标准的位置。我们发现,典型地很难自动找到与运行实例(甚至是非常普通的标准软件例如web服务器和数据库的运行实例)相关的一切。
[0133]在一个或多个实施例中,根据本发明的方面的快速迁移被认为特别适合于仅基础架构的迁移以及未改变的主OS版本呢,即,目标是到达MIaaS云但不想做出其他主要改变的时候。如802’所示,当“相同”的服务器被移到云中时,它现在在云硬件830上运行,并使用管理程序832。除此之外,存在有限的改变:
[0134]?操作系统的小更新(现在是OS’ 822’)——即,不同的驱动器、云提供者用户ID、IP地址
[0135].略微不同的基础架构软件(云管理工具一现在是Infra’ 808’ )
[0136]一个或多个实施例利用了下列见解:更新少数改变的事物,而不是单独选取所有未改变的事物并具有忘记某些事物的风险,这是有利的。现在参考图9,0S822 ;MW804 (包括其配置814)、806 ;基础架构808、代码810、脚本812、代码818和数据816被放在一起,移动到云中,且然后对OS822’和infra’ 808’进行小的更改。有利地,在该方法中,如果有任何事物在更改中无法工作,这很可能只是云服务提供者一侧的基础架构管理(因为它是最新添加的),而不是应用(其基本保持未改动)。当然,这已首先假设应用事实上可被虚拟化。当然技术人员将理解,给定这里的描述,需要特别关心例如服务器的新资源附加地支持云管理代理。
[0137]图10示出了替代的方法(重新安装/重构平台),其不使用上述快速迁移技术。这是MIaaS提供者典型地期望其用户去做的,但在时间和金钱方面通常是不可行的。在该图中,在从云目录为实例提供与原来的0S808类似的0S’808’并且刚刚安装了现成软件之后,基本上所有事物被逐个移动。沿着这些路线存在某些当前可用的工具,但其仅可用于可能的现成软件的小的子集,但几乎没有可用的工具来移动额外的事物,例如脚本、代码等,甚至也没有可用的工具来只是列出所有事物以用于后续的传送。在安装之后移动“其他的一切”也决不是容易的选项一在文件系统以及OS数据结构(例如特别是WINDOWS上的注册表)两者中,OS、应用和配置/数据/自定义代码是高度关联的。
[0138]现在考虑快速迁移(即在图4-7和9所述的新技术,即图4的步骤406和408,或者图5的元素556、558、570)中的交错的调整和注册的核心选项。仅通过示例而不是限制,特别考虑若干个核心选项,以将导入的实例的注册流程添加到MIaaS云:
[0139]第一选项:针对最紧密相关的目录映像(分析和计划阶段524已决定实例将被调整以模拟该映像)来运行供应流程。然后用从目录映像产生的实例交换导入的实例,在该导入实例上已经进行了大多数调整(例如额外的补丁、安全合规性调整)。这可以针对挂起的映像在映像文件级别上执行。例如,如果提供的实例具有某种身份(例如IP地址),且由于MIaaS管理需要它但无法事先知道它,从而现在需要将其传送到导入的实例,则可能需要在供应后对导入的实例进行某些调整。注意到这样的交换以及交换后的调整不能由未更改的MIaaS云的用户来执行;它需要特别的授权,并且为了足够高效和安全,自动化工具被添加到MIaaS管理系统。
[0140]第二选项(见图11):更改供应流程,从而它仍然执行大部分注册工作,但在某些点上选取导入的实例的映像而不是目录映像。如果供应流程对映像执行实时动作(例如代理安装),这些也可被重用(而不是在注册流程之前的调整中执行)。如果可能,保留供应流程和新注册流程的公共部分,作为实际的公共组件(公共的子程序、子工作流等)。
[0141]现在参考图11,这里描述了 MIaaS云环境(IBM SCE+是非限制的例子)中的示例性供应流程。在步骤1101,用户访问客户门户和服务目录1110,这是MIaaS的BSS(568、696)的一部分。在一个或多个实施例中,“采用”或“导入”是目录1110中新的服务类型(与被设计为没有新的快速迁移方法的MIaaS云相比),且可用于特定的角色。在某些情形下,该方面可以通过对MIaaS云中现有的用户接口(UI)进行相对较小的改变来实现。合适的参数可以被传送给下面描述的供应过程。如图所示,服务请求可以涉及服务目录;请求的接收、请求的完成以及对虚拟机供应状态的更新。在某些情形下,在使用时示出服务器资源使用状态。
[0142]在步骤1102,用供应引擎1112来执行供应。MIaaS供应可以包括从门户1110接收请求;使用映像来创建实例;创建虚拟服务器,其包括供应资源需求,例如CPU、存储器、盘、主机名、IP地址和/或子网;安装用于管理的代理、配置代理、连接到虚拟局域网(VLAN);#及/或服务器验证。针对导入映像的注册作为对该供应流程的调整,一个或多个实施例在步骤1102的“使用映像来创建实例”的子步骤中选取导入的映像而不是目录映像。因此,与图5相关,该子步骤变成在生产区域中从导入的实例创建实例558。如果着陆区域从生产区域物理分离,这实际上涉及将调整的实例554从着陆区域复制到生产区域。如果着陆区域是虚拟的,甚至可以将实例保持在原处,但现在将其地址(名称、指针)提供给供应流程。
[0143]在快速迁移方法的一个或多个实例中,在创建虚拟服务器期间,如在导入的实例或步骤524的计划中那样创建精确的CPU、存储器和盘(由于云可能不具有和导入的映像完全一样大小的资源,典型地将选择下一个较大的足够的大小)。某些实施例使用双宿(dual-homed)主机的实例,其具有云服务提供者的内部IP地址(用于MIaaS的云管理系统对实例的访问)以及面向客户的客户地址;这典型地不同于导入实例的老的IP地址,且由此该实例上的地址必须被更改为云管理系统所提供的面向客户的地址。
[0144]需要注意,诸如“必须”或“应该”等单词论述了示例性实施例中强制性的项目,但在其他实施例中可以是可选的。对权利要求不会有任何限制,除非在其中如此陈述。
[0145]在某些情形下,针对代理的安装和/或配置,如果MIaaS云为了相同的目的而使用不同的代理或工具,提供新的流程来处理之前的代理,例如性能监控代理或备份代理。具体的非限制的例子包括可以从美国加州Sunnyvale的赛门铁克公司获得的Altiris产品以及可以从美国德州休斯顿的NetIQ公司获得的产品。处理这样的代理可以包括例如卸载或者将权限从管理员权限降低为用户权限、或者工具中的策略改变。但是,作为替代,甚至可以在启动供应流程之前执行该流程,作为着陆区域中的调整。
[0146]在步骤1103中,创建虚拟服务器。在图11的非限制的例子中,这可以使用用于INTERL技术的虚拟化管理器1116(例如,利用如1120所示的(美国加州Palo Alto的VMware公司的)VMware ESX VM)或使用用于POWER技术的虚拟化管理器1118 (例如,利用如1120所示的IBM PowerVM逻辑分区(LPAR);美国纽约州Armonk的国际商业机器公司)来执行。在任一情形下,可以 使用合适的存储,例如存储区域网络(SAN)存储1114。在其他实施例中可以使用其他类型的技术。该步骤可以包括从供应引擎1112获取请求;分配合适的计算资源,例如CPU、RAM、盘空间等;复制映像;将映像放置于物理服务器上;启动操作系统和中间件;以及/或应用IP和主机名。在采用该流程以用于快速迁移中的注册的某些实施例中,另一步骤包括为测试准备自定义的访问。在没有迁移的MIaaS供应中,不需要该测试,因为这是标准的目录实例,但在这里,正在处理导入的调整的实例,且执行用户接受测试560是合适的。
[0147]在步骤1104,在供应引擎1112的帮助下执行服务器验证。这可以涉及例如检查管理代理的正确安装和配置;安全扫描(例如针对端口、密码策略等);检查用户ID的有效性;运行健康检查;将服务器信息记录到主数据库中;以及/或向合适的管理工具(例如可以从美国纽约州Armonk的国际商业机器公司获得的IBM Service Delivery Manager (SDM))?艮告。
[0148]一个或多个实施例有利地使用调整工作流中的典型更改的自动化,从而这些测试(例如安全扫描)典型地不会失败一事实上,MIaaS云的这些验证步骤可被看做是在迁移至该MIaaS云时必须哪些调整的基本规范。[0149]步骤1105包括更多地在BSS层上的最终验证,这与步骤1104中的OSS层验证相反。这可以包括例如验证报告的SDM检查;确认请求;同意VM (即实例)发布给客户;云服务提供者将客户用户添加到服务器(如果还不存在);以及/或向客户提供服务器接入。在某些实施例中,在迁移时将更早地提供访问以用于测试,如步骤1103所述。
[0150]现在将提供关于可在一个或多个实施例中执行的若干步骤的示例性的非限制的细节。
[0151]发现(步骤518)
[0152]在某些实施例中,针对第一次运行一在第一变换计划之前,标准工具(例如可以从美国纽约州Armonk的国际商业机器公司获得的IBM Tivoli Application DependencyDiscovery Manager (TADDM)> IBM Galapagos工具等)可以在生产系统上在实际迁移之前很好地运行。关于 IBM Galapagos 工具,例如见 Galapagos:model_driven discoveryof end-to-end application—storage relationships in distributed systems, IBMJournal of Research and Development archive, Volume52Issue4, July2008, Pages367_377 以及 Nikolai Joukovj Birgit Pfitzmannj HariGovind V.Ramasamyj Murthy V.Devarakonda: Application-Storage Discovery; SYST0R2010, Haifa, May2010o 在某些情形下,为了易于安装到客户环境402中,这些工具可被预先安装在设备(appliance)(小物理服务器)上。该过程统一了这些工具、客户输入以及从特定的可用客户库的加载。在至少某些情形下,云服务提供者可以请求额外的访问来完成实例特别是虚拟实例522的文件系统副本(但是在该过程中没有什么依赖于此)。
[0153]在某些实施例中,针对第二次运行,以每一波的方式来执行相同的过程。S卩,在迁移的(例如)几周前,有针对每一波的此后的再次发现。可以使用相同的工具,其通常具有额外的选项和插件来获得更多的细节。在该第二次发现518之后,在一个或多个非限制的例子中,针对代码和配置来执行更改冻结,从而后续地步骤可以信赖来自发现的信息是当前的。
[0154]分析和计划(步骤524)
[0155]该阶段决定业务应用是否能够被迁移到一个或多个MIaaS云环境(SCE+是非限制的例子)以及使用哪种迁移方法。假设这与组织可能具有的(用于与MIaaS不同的其他类型的迁移和IT变换的)一般迁移计划工具(例如IBM Migration Factory)进行集成。在该工具中,到MIaaS的迁移应共享信息,例如用于不可虚拟化的软件、软件-OS兼容性、以及非云迁移的升级成本。这些例如可作为位于计划设备下面的数据库中的静态表来获得。决定什么工作负载进入到至MIaaS的快速迁移路径的一个重要标准是它们已经具有正确的主OS版本。例如,如果MIaaS云中的映像目录仅包含以Windows2003、2008和Red HatEnterprise Linux (RHEL)5.6作为操作系统版本的映像,计划可以决定仅针对已经具有这三种操作系统中的一种或者至多额外的RHEL5.1到5.5 (从而在调整时需要很小的升级)的源实例520或522来使用到该MIaaS云的快速迁移。如果在具有这些操作系统中的一种的实例上存在不可虚拟化软件或者其他排除标准(特殊硬件,可能是集群),该实例仍然需要进入不同的目标环境,或者首先被显蓍地修复(步骤526 )。在某些情形下,调节过的工作负载未被迁移,但这不是要限制权利要求的范围,除非其中显式地说明。在某些情形下,该方面是通过扩展静态表和发现来执行的,以最小化潜在的问题;尽管给定这里的内容,技术人员将理解,可以使用对物理到虚拟技术的可能性进行分析的被适当地调整的标准分析技术来实现该方面。
[0156]在一个或多个实施例中,该阶段还包括对源实例的补丁状态与MIaaS云的标准的兼容性进行分析;这专用于到MIaaS云的迁移。
[0157]在一个或多个实施例中,该阶段还包括选择映像大小。在至少某些情形下,简单地保持大小,除非需要增加它以符合在调整期间必须安装的新代理。如果MIaaS云仅允许特定的固定映像大小(关于CPU、存储器、盘存储等),可能需要在以后将映像大小调整为下一个更大的合适的大小;但是,这不应是排除性的标准。
[0158]在一个或多个实施例中,该阶段还包括波计划,即,将一起迁移的服务器分组。这例如可以使用标准的迁移工具来执行(例如在上述美国专利申请公开20110213883和20120109844中公开了该方面);使用依赖性、位置、子网等;可选地,可以在该阶段尝试释放硬件等。需要注意在一般情况下,不能确保没有跨波依赖性一某些环境过于互连。
[0159]在至少某些情形下,在该阶段应计划安全区域并且还应计划特定的云池(B卩,对云提供的实例进行分组)。参考下面关于图14对请求GUI的讨论。 [0160]某线测试和各份(步骤528)
[0161]在基线测试中,客户(或者迁移组)执行他们还会在迁移后应用的所有测试,以确保现有的系统通过所有那些测试。在一个或多个实施例中,实际的测试与用户接受测试(UAT)中的相同。这可以涉及例如写入数据库等的某些UAT测试,从而它们无法在生产服务器(例如生产区域574)上执行;来自客户环境的测试服务器然后可被用于基线测试,尽管那里的实际的工作负载部署会比生产配置更简单。
[0162]在至少某些情形下,由客户来进行备份,且客户验证它起作用,因为实例捕获会导致问题。在某些情形下,云服务提供者不会在客户一侧进行备份。
[0163]在某些情形下,客户可以在该阶段执行额外的步骤。例如,启用以下讨论的捕获过程,特别地,存在其他事情需要客户来做。
[0164].确保对其自己的开发者存在更改冻结;
[0165]?给予迁移组(可以是内部的、来自云服务器提供者或其他方的)对要迁移的实例的根权限;
[0166].给予迁移组用于迁移的现实的更改窗口,因为物理到虚拟(P2V)被视为更改,即使是它在后台运行的情形下。
[0167]实例捕获
[0168]可以针对该步骤来使用多个变体。参考图12。将展示非限制的例子,所有例子都可有效地用于到虚拟化环境的任意传送:
[0169]?如果客户环境402中的源实例520仍然是物理的,如图536所示将涉及P2V操作(物理到虚拟)。存在用于此的标准工具,例如,上述PlateSpin工具,以及可以从上述VMware公司获得的VMConverter工具。
[0170]?如果存在多个驱动器,可以由相同或不同的工具来处理。数据驱动器传送例如可以比启动驱动器传送更早开始,并用再同步工具例如IBM Softek TDMF软件来执行,以用较短的更改窗口来适应大量数据。
[0171].如果需要P2V操作,它可以是本地的(即,在客户环境402中首先创建虚拟机或映像),之后是传输,或者它可以和传送集成,即,新的虚拟机或映像文件在目标即“着陆区域”572中立刻存在。
[0172]在一个或多个实施例中,客户面临的重要方面包括:
[0173].迁移组需要获得映像的根/管理员权限
[0174].如果非启动卷存在并通过如上所述的再同步工具来传送,该工具必须被事先安装
[0175]?更改窗口最迟应在这里开始
[0176].应用典型地在P2V时间期间关闭
[0177].在所有传输都是通过WAN514的情形下,应该存在“开始区域”,在此捕获的映像等待传输(至少针对大映像,小映像例如可直接通过PlateSpin工具来传输)。
[0178]实例捕获可以包括合适的关闭过程。在某些实施例中,在潜在的P2V步骤之前,企业应用(也被称为工作负载)被关闭(如果在备份期间还没有这么做)。这意味着从用户的角度来关闭它们一在多组件的工作负载下,这并不意味这关闭所有组件;例如,可以仅禁用前端web服务器。在捕获步骤中甚至没有任何软件组件运行会更安全(冷P2V),但在事物运行时用给定的工具这样做是可能的(热P2V)。在一个或多个实施例中,应用所有者限定什么被关闭,且优选地执行该关闭,因为迁移组被分配了基础架构级别的任务,对此可能没有全面地理解。
[0179]例如,实例捕获可以包括用于物理服务器的P2V步骤。对于已经虚拟化的服务器,特别是在VMware上,该步骤需要的很少。在一个或多个实施例中,在P2V结束时,不再允许对源进行更改(如果在备份期间还没有禁止更改),因为它们不会再被传送到目标。即,典型地,现在整个源实例被关闭以确保该目的。如果实例已经被虚拟化,在要传输的映像完成之前、或者在集成的传输中、至少在该传输中的最终再同步之前关闭该实例。
[0180]如果捕获步骤与传输步骤分离,将为捕获的实例提供“开始区域”,即与传输技术接近的用于它们的存储空间。
[0181]传输到云服务提供者(包括数据)
[0182]数据传送可以通过网络或物理介质来执行,这依赖于网络带宽和物理距离。在某些情形下,这可以使用再同步工具(一个例子是IBM Softek的TDMF)来执行,特别是针对大映像或非启动驱动器。工具例如TDMF应被事先安装,且如果存在大数据集作为非启动驱动器,后台数据传送可比P2V更早开始。如果确定启动驱动器不包含普通“数据”,至少在某些情形下,可以仅对该驱动器进行更改冻结,即,仅同步其他驱动器。当然应给予客户可接受性足够的关心。
[0183]到着陆区域应该有足够的带宽,典型地比到MIaaS云的标准WAN连接大得多,因为在照常运行阶段711中需要。在某些情形下,可以使用特殊的光线路。可以将WAN优化器加到该光线路(例如可以从美国加州旧金山的Riverbed Technology获得的WAN优化器)。在至少某些实施例中,大小设定应用于最大波负载而不是平均。另一个选项是使用物理存储介质,例如高密度SATA (串行ATA (SATA或者串行AT附件)盘阵列并通过信使或类似方式来传输。通过使用再同步工具将数据复制到它们,在此之后可以通过网络来再同步。
[0184]着陆区域
[0185]一个或多个实施例使用“着陆区域”,即与特定实例的最终云位置相同的数据中心中的环境,并且具有相同的硬件和管理程序(例如,对于VMware ESX VM是相同的ESX版本),该导入的实例可以在其中运行。在某些情形下,对于初始的传输,如果针对映像文件来单独执行,所需的只是足够的存储空间,如对于任何传输那样。但是,最迟在第一次功能测试时,用于导入的实例的运行时环境应已可用。在一个或多个实施例中,每个数据中心至少有一个着陆区域,因为一旦实例被传送到云服务提供者,不会使用进一步的WAN传送。可能存在甚至更多的着陆区域,特别是如果数据中心包含多个物理分离或分别管理的生产区域;于是每个生产区域可以有一个着陆区域。
[0186]需要被复制的客户的任何安全分区可以虚拟地执行,即通过云服务提供者的VLAN和防火墙来执行,但除非客户也在生产区域中需要特定安全区域的物理分离(在云中不常见),实例都可以在相同的硬件上着陆,受到相同的管理软件的控制。
[0187]如上所讨论的,整个着陆区域可以从(相应的)生产区域物理或虚拟地分离。在一个或多个实施例中,确切的位置和地址是相关的考虑。在虚拟分离的情形下,优选地将每个实例导入到物理上接近其在注册之后将停留的位置,从而不需要额外的复制。例如,如果生产区域的子结构分为若干个单元,其中,例如,每个单元被VMware vCenter Server或TSAM
(可以从美国纽约州Armonk的国际商业机器公司获得的IBM TiVO丨i?服务自动化管理器软件),且着陆区域甚至在这样的单元中都是虚拟的,在从着陆区域传送到生产区域时,实例可以保持在相同的物理服务器和存储上。例如,仍然属于着陆区域的实例可以具有“容许”标记从而TSAM知道它们在那儿并且还未在生产区域的意义上被管理。但是,如果为了额外的安全性和更低的复杂性,着陆区域位于生产区域以外的其他单元中,则需要实际的复制,并且主要在生产区域中执行的注册流程必须被给予实例在着陆区域中的地址以及从该地址复制的权限(例如通过在防火墙中开启特殊的端口)。
[0188]功能测试
[0189]在传输到云服务提供者之后,应当进行测试来验证P2V和传输正常地工作了。为此,可以使用在非云的P2V变换中使用的标准方法,因为到目前为止还没有专用于MIaaS的调整。最小测试是实例至少能够启动。在某些情形下,该测试可限制在OS、存储等;在其他实施例中,它可被扩展到软件或甚至整个业务应用仍然工作。在某些情形下,可以存在从关闭的时间开始在运行的事物的列表。在某些情形下,迁移组提供自动重启的能力。另一方面,在某些情形下,这是由客户来处理的。该测试典型地与完全的基线测试不同。
[0190]在调整之前/期间备份实例/建立实例快照
[0191]直接在传输到云服务提供者之后,并且可选地在执行测试的任何步骤之间,可以(用VMware快照技术)进行备份以实现更容易的修复。但是,特别是对于成熟的过程,人们可以决定不做这些中间的备份,以便在大多数一般正确的情形下节省时间。在涉及人工决定的步骤之前/之后,备份特别有用,而自动化步骤可以容易地从第一个备份开始重做。
[0192]修复550
[0193]在至少某些情形下,这主要是人工步骤。如果出现了错误,典型地需要调试。如果遇到了太多困难,需要从当前的一波即本周末(或其他相关时段)的迁移中去除该实例或可能整个业务应用。还需要记录这种情形,从而未来可以在发现518和分析及计划528的阶段捕捉到这种情形。
[0194]在云服务提供者的VMware ESX虚拟机等上面的实例[0195]此时,使用刚刚通过功能测试的运行实例开始调整流程。
[0196]采用和调整子流程556
[0197]在至少某些情形下,通过对如上参考图11讨论的供应流程的小的修改来执行采用(在这里也可互换地被称为注册)和调整。对于更一般的视图,应参考图13集中在特定于迁移的步骤上(图11示出了“非迁移”步骤并在下文中讨论特定的迁移步骤)。在步骤1302中,确定是否需要或想要任何采用前调整,即在任何注册步骤之前且与之分离地执行的调整,即涉及MIaaS云BSS和0SS568的步骤。该确定可根据需要参考作为分析和计划步骤1306的输出的决策文档等。在步骤1304,以来自分析和计划步骤1306的合适的实例参数(以及云区域)来开始采用流程。在步骤1308,门户流程传递(pass through) “采用”参数,即表示需要执行流程变体的参数,在该流程变体中导入实例被注册。(该流程修改可以在作为MIaaS门户的基础的系统中执行,例如,在可以从美国纽约州Armonk的国际商业机器公司获得的IBM Tivoli服务请求管理器(TSRM)软件中执行)。在步骤1310中,发生供应,并选取导入的实例,并且调用任何新的调整子流程(例如可以在TSAM中执行)。在步骤1312中,创建虚拟服务器。(如果实例保持相同,即如果如上所述着陆区域完全是虚拟的,则不需要这么做)。(这可以通过MIaaS云例内部例如在TSAM中的普通实例创建来执行)。在步骤1314中,执行MIaaS云的服务器验证(假设MIaaS云具有该验证并且不完全依赖于之前的步骤,从而成功而不用测试);优选地没有更改,但在该点上,期望迁移的实例会比从目录映像提供的实例出现更多的问题,因此可以保留更多的用于修复的时间。
[0198]在步骤1316中,通过向客户提供合适的密钥来为客户测试访问准备实例。在步骤1318中,如果需要,验证请求(即该流程的初始输入)的满足;在一个或多个实施例中,这可以通过缩短和自动化的过程来执行,在所述实施例中,与这是对MIaaS云门户的客户请求的普通情形相比,这仅是更大的迁移流程中的子流程。
[0199]所示子流程对应于步骤556。
[0200]在任何这些子流程之间会出现备份/快照和测试(相邻的总体步骤);甚至是在它们内部,特别是在单独的调整之后的供应流程1310中,也会这样。
[0201]以实例参数1304来开始采用流程
[0202]在非限制的例子中,门户在TSRM中执行,并包括图形用户界面(⑶I)和REST API(应用程序接口)。在一个或多个实施例中,通过REST API来开始被认为是合适的,因为从分析和计划步骤524的结果所有参数应是清楚的。这些参数可以位于数据库或另一定义良好的库中,从而可以由软件检索。而在图5中,在客户环境402中示出了分析和计划组件,其中出现被发现的数据,在某个时刻,用于调整步骤556的数据的相关部分应被传输到MIaaS云环境410,特别是其云管理区域680 (在图5中忽略了该箭头以避免混乱)。传送代理682和传送核心组件690可以将其作为传输映像之外的附加任务来承担。但是,在某些情形下,可能需要通过⑶I来初始地开始以更容易地对活动进行跟踪。
[0203]在一个或多个实施例中,与该子步骤相关的分析和计划步骤524的结果应包括实例数据、分区计划等,从而正确的参数可被容易地输入到RESTAPI或由人操作者输入到GUI中。
[0204]需要为着陆区域中的实例提供命名/位置方案,从而在此时,可以输入与哪个实例将被注册相关的信息。在一个或多个实施例中,在该名称下,VMware vCenter服务器知道所讨论的实例。在一个或多个实施例中,用实例的实际值来对GUI输入(大小、OS)进行自动检查是有用的。
[0205]图14示出了来自MIaaS门户GUI门户设计自服务中心1402的示例性“CreateServer”(创建服务器)弹出窗口 1404。迁移服务器被分组为一个项目(project),且如果每个迁移请求可以包含多于一个实例(在该⑶I中被称为映像),则提供“Configuration Set”(配置集)选项。给予用户选项来填上他或她想要使用的映像(image)的名称,或者点击放大镜来查看可用映像的列表。在一个或多个实施例中,VM大小信息应该是映像的元数据的一部分,并可能具有对它进行修改的选项。“Migrate Server"(迁移服务器)按钮开始实际的注册流程。门户现在可以执行特定的活动,例如在存储中记录开始的流程,以及允许从GUI或REST API查询其状态。
[0206]门户流程一传递“采用”参数1308
[0207]典型地,门户是与供应弓丨擎1112分离的软件组件1110(特别地,是BSS的一部分),所述供应引擎是执行实际注册的组件(通常是工作流引擎并且是OSS的一部分)。因此,门户将注册请求传送到供应引擎。与在这两个组件之间传送的普通供应请求相比,被迁移的实例的“注册”或“导入”的选择以及该实例的位置/名称被传递,即,这些是该API中的该请求的新参数。
[0208]供应流程一实例选取步骤1310
[0209]在一个或多个实施例中,基于着陆区域中的合适的命名/位置方案以及供应引擎1112 (例如TSAM),选取是清楚的,该供应引擎获取从门户1110 (例如TSRM)采用的实例的名称/位置。在非限制的例子中,底层的VMware vCenter服务器中的实例的名称可被使用。该名称可能不是全局唯一的,但如果使用主机名,应该是可接受的,所述主机名可以假设在其他方面已经都是不同的。
[0210]在着陆区域被物理分离的实施例中,可以使用特定的防火墙设置以及复制过程来执行实际的选取(这和从MIaaS映像库获取映像略有不同)。
[0211]供应流稈一调糖概沭1310
[0212]现在回到图15,在1502,注意迁移之后但在调整之前的客户实例,S卩,直接在传输538之后的着陆区域中的云管理程序554上的实例,并且在1504,在迁移和调整之后的客户系统(被分解为客户部分1506和云服务器提供者部分1508),即,如它将在558处的生产区域中成为的那样。针对应用/中间件层1510,在该级别典型地计划做很少或不做更改(特别是因为在该例子中考虑仅迁移到MIaaS云而不是PaaS云),除了由某些基本OS配置方面例如IP地址的潜在更改带来的某些配置更改。在一个或多个实施例中,在该流程中不涉及应用,因为P2V典型地工作良好并且该流程可以用标准的P2V技术来执行。针对应用/中间件管理层1512,在该级别典型地计划做很少或不做更改,除了与安全方面的或者由某些基本OS配置方面例如IP地址的潜在改变带来的某些配置更改。
[0213]针对OS管理层1514,该流程包括移除不再需要的客户管理套件组件以及对那些需要的进行策略调整;以及安装云服务提供者的标准管理套件和云服务提供者的云管理工具(关于后者,至少在某些情形下,在之前的方面实现代理,且中央工具已经存在)。在某些情形下,通过标准的供应流程来执行安装。移除和策略调整是重要的任务。
[0214]关于方面1512、1514应注意,某些工具对于OS和App/MW层来说是公共的。[0215]针对OS层1516,在一个或多个实施例中,根据云服务提供者接受基本OS的需要来安装OS补丁的最小集合(在替代的实施例中,这可被实现为在其他方面为BAU云管理中的单独流程)。在某些情形下,执行“开放端口”检查。在一个或多个实施例中,在基本操作系统级别不需要更改,除了所需的OS配置更新例如IP地址。
[0216]处理代理的诜项
[0217]在一个或多个实施例中,针对每种代理类型确定的重要选项包括:
[0218]?可以忽略特定的代理?(最容易的流程)
[0219]?必须保留某些代理?在非限制的例子中,可能存在确定的态度来保持AD(可以从美国华盛顿州Redmond的微软公司获得的活动目录认证产品)和Altiris (用于应用)。在一个或多个实施例中,用于应用管理的一切应当保持,并可能具有更改。
[0220]?应该使某些代理无效?这意味着将它们关闭,但不是卸载它们。这是在代理看来不再需要、但根据给定的信息这还不是太清楚从而卸载有风险的时候的选择。
[0221].某些代理可以/必须被完全卸载?在某些情形下,这可以是合适的,以整理映像,或者因为代理需要资源(例如NetIQ的监控需要很多CPU)。在一个或多个实施例中,完全的卸载从来不是强制的,因为客户在这些服务器上可能具有各种类型的事物,并且云服务提供者对此进行判断。
[0222]?代理典型地不允许具有根/管理员权限。在此时,应确定必须保留的那些是否可以运行而没有根/管理员权限;并且它们需要哪些更明确的权限。一个例子是仅用于补丁应用的Altiris。
[0223]在某些实施例中,·云服务提供者可以询问客户如何使用这些工具、客户具有什么策略、工具在哪里安装、等等。
[0224]还应注意,云服务提供者计划的任何更改将需要大量的新发现努力一至少如果客户的安装和其他软件的安装一样可变和非标准化。
[0225]小版本、修订包和安全补丁更新
[0226]值得注意的是,可以从美国纽约州Armonk的国际商业机器公司获得的BigFix工具,现在被称为IBM Tivoli端点管理器,被认为是用于安全补丁的特别有用的工具;但是,其他实施例可以使用其他工具。
[0227]其他纟目件中的地址审改
[0228]在非限制的例子中,进行下列地址选择:
[0229].映像保留其DNS名称,即在切换期间,客户将更改用于他们的域的DNS条目(这比改变DNS名称要更容易得多,DNS名称可在应用/中间件层1510及其管理1512的很多组件中使用)。
[0230].实例在新的虚拟NIC (网络接口控制器)上获得两个新的IP地址,以启用MIaaS云的管理和备份任务,而不会干扰客户IP地址和(虚拟)NIC上的普通流量。
[0231]?来自客户环境的IP地址被替换为MIaaS云生产区域的子网中的地址;这是应该在以上DNS条目中输入的。
[0232]因此,在一个或多个实施例中,不需要改变对迁移的实例进行寻址的其他服务器和客户端,假设所述其他服务器或客户端使用DNS名称(而不是直接使用IP地址);这逐渐变得常见。[0233]在某些情形下,在想要降低成本时,迁移组无法容易地确定客户是否使用IP地址来寻址。在这样的情形下,向客户提出要求以确保不会是这种情形,这是合适的。如果该要求被违反,在用户接受测试560中会出现问题,且修复会将实例或整个工作负载返回给客户。该问题独立于迁移路径或目标,特别是迁移至MIaaS云的事实。
[0234]创律虚拟服备器1312
[0235]在一个或多个实施例中,如果可以仅保持实例并且至多通过虚拟交换机或防火墙更改来将它置于不同的VLAN中,则不需要在此时创建任何服务器。否则,虚拟服务器创建和在MIaaS云的标准供应中一样来工作。
[0236]为客户测试访问(密钥)准备实例
[0237]在采用和调整流程的该时刻,需要在该实例自身完成的所有重要的事情都已被执行,并给予客户用于测试映像的访问。在该阶段,大多数客户ID仍然在实例或者相应的活动目录(AD)中。由于代理权限降低而改变的那些客户ID典型地应该已被设置。在某些情形下,云服务提供者会需要分发密钥,如果映像是基于密钥来访问的。在一个或多个实施例中,这和在本文其他处描述的用于目录映像的供应流程中一样地工作。
[0238]服备器骀证1104
[0239]这样的认证可以不相对于目录映像的供应流程更改。在一个或多个实施例中,在该时刻的失败被认为在客户实例的情形下比在云服务提供者目录映像的情形下更显著可能地出现。至少在某些情形中,云服务提供者可以提供合适的修复。
[0240]优选地尽可能多地自动执行该认证以及测试失败时的合适的修复。但更好的是,每当可以执行自动化测试和修复,在调整步骤中采取这些方面是可取的,即使为了合规或审计的原因而在服务认证阶段重复它们。
[0241]请求认证1105
[0242]在迁移的场景中,在事先已知每个周末(或者其他时间段)会发生什么时,该方面优选地被保持较短并且大部分自动化。但在UAT之后来自客户的最终许可能仍需要手工输入。
[0243]此时,在采用和调整的细节之后(步骤556以及如图558所示的实例随后传送到生产区域中),可以恢复图5的整体快速迁移流程。现在进行用户接受测试(UAO560 (典型地不仅是一个实例的,而是该实例以及可能其他实例支持的业务应用的)。如果测试失败,应和客户一起进行人工决策,并考虑下列方面:
[0244].问题可能是能在云生产区域574中局部解决的小问题(例如DNS或防火墙未被正确地启动)
[0245]?可能已知问题是调整失败一特定的调整可被跳过,例如特殊的安全补丁。如果单独的操作(例如尝试安装安全补丁)没有安全的回滚,云服务提供者可以回滚到之前存储的实例。如果在该调整中有人工决策,云服务提供者在某些情形下可以再次尝试不同的决策。
[0246].在某些情形下,如果不知道问题是调整失败,或者无法在更改窗口内修复问题,或者变化超过特定的阈值(例如,多于(例如)五个安全补丁不能被应用),则取消该实例(以及可能整个业务应用)的迁移。典型地基于备份532来重启客户实例520或522。
[0247]切换并采用新实例
[0248]如果UAT通过,客户开始使用云中的一个业务应用或其他迁移单元的实例。在如以上例子中那样做出寻址选择时,客户的DNS在此时改变;这可以包括改变反向DNS条目一可能作为标准过程的一部分。在某些情形下,更改窗口可以在这里结束。如果客户有特定的报警,例如web入口页上的“应用关闭”,现在可以将它们去掉。如果需要,可以提供合适的客户训练。
[0249]值得重复的是,一个或多个实施例提供可跟踪和/或回滚能力的优势。此外,在这方面,可跟踪是很重要的优势,并且托管环境清楚地记录对映像执行的每个步骤且特别是调整,这非常有用。调整引擎以及TSAM/TSRM具有为完全透明/更改受控的迁移创建实例特有的日志的能力。关于回滚能力,调整引擎以逐步的模式来操作,且提供如果出现错误则回滚特定调整的能力。该能力与快照一起创建了相对安全的环境来执行所述的迁移/调整步骤。
[0250]重述
[0251]给定到目前为止的讨论,可以理解,一般来说,根据本发明的方面的示例性方法包括将外部实例684从客户环境402传送到目标基础架构即服务云环境410作为映像的步骤。该步骤例如可以通过组件690可选地通过与代理682交互来执行。另一步骤406包括将外部实例调整为基础架构即服务云环境的标准以获得调整的实例。该步骤例如可以通过组件692来执行。又一步骤408包括将调整的实例注册到基础架构即服务云环境的管理系统中(一般是410 ;在一个或多个实施例中特别是696、698)。
[0252]一般来说,调整可以包括在外部实例运行时调整该外部实例,或者调整外部实例作为上述映像。
[0253]在某些情形下,注册包括针对基础架构即服务云环境的标准目录映像(选择与外部映像类似的标准目录映像)来运行(例如如图11所示的)供应流程的至少一部分;以及用外部实例的映像交换标准目录映像。通常,该交换可在供应流程中或者在供应流程之后执行;在供应流程中执行时,这被称为在供应流程中选取外部实例的映像,而不是交换。此外,“在供应流程之后”交换应被理解为包括在步骤1102之后(且可选地在步骤1103的大部分或全部之后,但是在1104之前)。
[0254]此外,在这方面,考虑三种方式来进行。回顾图11示出了针对目录映像的供应流程。在某些情形下,通过供应流程来进行直到几乎最后,如步骤1101-1103那样,以获得供应的实例;然后抛弃该供应的实例并将它替换为正被迁移的实例(这被称为交换)。在某些实施例中,目录映像从未被真的置于服务器上。在目录映像将被复制的时点,选取实例并使剩余的工作流程在迁移的实例上运行,从而在结束时需要做更少的工作(图13步骤1310)。在一个或多个实施例中,这一时点是在步骤1102的子步骤“创建虚拟机”中。步骤1103详细说明了该创建。在虚拟机创建中,这一时点是在“复制映像”的子步骤中一在这方面,被复制的是导入实例的映像而不是目录映像。
[0255]正如所述,在一个或多个实施例中,基础架构即服务云环境是托管基础架构即服务云环境。于是,在这种情形下,传送包括报送至托管基础架构即服务云环境;调整包括调整至托管基础架构即服务云环境的标准;并且注册到管理系统包括注册到托管基础架构即服务云环境的管理系统。
[0256]正如其他处所述,在调整步骤中,在某些情形下,标准包括安全标准、基础架构标准、补丁管理标准、以及基础架构管理系统标准(例如工具如696、698的标准)中的一个或多个。
[0257]在某些情形下,额外的步骤524包括分析外部实例传送到目标基础架构即服务云环境的适合性;在该情形下,传送是响应于分析产生肯定的结果进行的。
[0258]正如所述,在某些情形下,在分析步骤中多个外部实例被当做一个整体。
[0259]在某些情形下,额外的步骤包括执行测试(例如参考判定框404、406、408);—般来说,这种测试例如可以在传输之前、在传输之后、在两次调整之间、在调整之后以及在迁移之后执行。另一步骤包括在测试失败(框404、406、408的“不成功”分支)时执行修复和放弃中的至少一个。如其他处所述,在某些情形下,在测试步骤中多个外部实例被当做一个整体。
[0260]在某些情形下,测试包括传送步骤之前的基线测试528,以及注册步骤之后的用户接受测试560。用户接受测试具有至少一个测试例。基线测试验证外部实例初始通过用户接受测试的至少一个测试例。
[0261]在另一方面,装置包括存储器(例如RAM30、高速缓存32);以及至少一个处理器16,其耦合到存储器且可操作地执行或促进上述方法步骤中的任一个、某些或全部。可选地,装置还包括多个单独的软件模块42,。每个单独的模块在计算机可读存储介质中实现,并且单独的软件模块包括传送核心组件模块、调整组件模块、以及注册组件模块;如本文其他处所讨论的。快照管理系统模块可选地包括图10中的子组件中的一个、某些或全部。
[0262]在某些情形下,传送核心组件模块从客户环境中的传送代理获取外部实例,并将外部实例定位在基础架构即服务云环境的云着陆区域中。在某些实施例中,至少一个处理器可操作地将调整的实例实例化到基础机构即服务云环境的云生产区域中。
[0263]在另一方面,在某些情形下,基础架构即服务云环境包括云着陆区域、云生产区域和云管理区域。在至少某些这样的情形下,至少一个处理器可操作地在云管理区域的控制下将外部实例传送到云着陆区域中;该至少一个处理器可操作地在云管理区域的控制下对云着陆区域中的外部实例进行调整;该至少一个处理器还可操作地将调整的实例实例化到云生产区域中;并且管理系统形成云管理区域的至少一部分。
[0264]在某些情形下,云生产区域包括第一类型的云生产区域计算机硬件以及在所述第一类型的所述云生产区域计算机硬件上运行的第一类型的云生产区域管理程序;并且云着陆区域包括第一类型的云着陆区域计算机硬件和在所述第一类型的云着陆区域计算机硬件上运行的第一类型的云着陆区域管理程序。对在所述云着陆区域中管理的实例比在所述云生产区域中管理的实例施加更少的标准,并且所述云生产区域通过物理和逻辑技术中的至少一种从所述云生产区域分离,以避免所述云着陆区域影响所述云生产区域的安全性。换种方式来说,云着陆区域是和云生产区域中的相同类型的一组计算机硬件(例如服务器、存储装置等)和管理程序,但对其中管理的实例有更少的标准,并且从云生产区域物理并/或逻辑地分离,从而不会影响云生产区域的安全性。
[0265]用于云迁移的管理基础架构分析
[0266]一个或多个实施例有利地提供了用于云迁移的管理基础架构分析的技术。在目前的迁移分析技术中,特别在是其自动化部分中,焦点在于关键中间件例如应用服务器或数据库。云计算范式的的一个重要的优势在于简化了管理,这主要来自标准化基础架构软件和标准管理过程。一个或多个实施例有利地将自动化迁移分析扩展到这些管理方面。[0267]在基础架构即服务(IaaS)云中,提供给消费者的能力是供应处理、存储、网络和其他基本计算资源,其中,消费者能够部署和运行任意软件,其可以包括操作系统和应用。消费者不会管理或控制底层的云基础架构,但对操作系统、存储、部署的应用具有控制,以及对选择的网络组件(例如主机防火墙)的有限控制。硬件基础架构即服务(HIaaS)云提供基本虚拟机作为服务。它还可以提供操作系统(OS)甚至软件,但典型地不会提供对OS或软件的支持。
[0268]另一方面,托管基础架构即服务(MIaaS)云提供了全服务的虚拟机。服务例如可以包括OS补丁以及对OS的安全性和合规的支持。MIaaS的一个重要方面是通过下列方式来简化管理:标准化到产生实例的目录映像的特定集合、在部署期间将这些实例自动关联到管理工具、以及/或不会给予客户OS级别的管理权限,从而实例上的操作系统保持为云管理员配置它们的样子。
[0269]至今为止(在云计算范式的出现之前),不需要分析与基础架构标准的兼容性或者与变换到它关联的成本。云计算机范式的一个方面涉及通过基础架构标准化增强的效率。移到云计算还反映了一种趋势,其中,信息技术(IT)运行成本已经超过IT投资成本。为了获得对云计算资源的投资的巨大好处,一个或多个实施例从分析开始有利地促进现有环境迁移到这种标准化基础架构管理系统和过程。
[0270]参考在本文其他处定义的IaaS云、HIaaS云、MIaaS云、实例、源实例、映像、目录映像、供应、重新安装迁移、基于映像的迁移、以及快速迁移到MIaaS云的定义。
[0271]现在参考图16,并注意云描述16300 ; 16100处所示的对要迁移的源系统的发现和分析(示例性源系统本身在图17中示出);以及基础架构比较引擎16200来执行两者之间的比较(也被称为分析、映射和/或匹配)。云描述16300包括云基础架构软件标准和/或配置(“配置”)16310、16320。其中还包括云基础架构管理的应用级别的描述16330 ;例如,云提供的服务级别协议(SLA),或者非功能需求,其可被设置为应用接口(API)的一部分。可选地,描述16300还包括云基础架构管理过程16340。
[0272]针对要迁移的源系统的发现和分析16100,步骤16100包括发现源基础架构客户端和服务器;步骤16120包括发现源基础架构配置和/或日志;并且步骤16130包括(例如通过推导来)获取源基础架构管理的应用级别描述。可选的,过程16100还包括步骤16140,即针对源的基础架构管理过程的发现和/或学习。
[0273]过程16200包括源和目标云之间的比较。步骤16210包括源和云软件之间的匹配,可选地考虑变换成本,并且基于云基础架构软件标准16310和来自步骤16110的发现的源基础架构客户端和/或服务器。在一个或多个实施例中,该匹配过程涉及查找冲突,如本文其他处描述的。
[0274].源基础架构管理组件管理至少一个对象,至少一个强制目标基础架构管理组件将在目标云基础架构中管理该对象。
[0275].源基础架构管理组件使用至少一个资源,至少一个强制目标基础架构管理组件将在目标云计算架构中使用该资源。
[0276].客户端上的强制目标基础架构组件的当前缺失
[0277].不同版本的强制目标基础架构组件的存在
[0278].具有不同配置的强制基础架构组件的存在[0279]在步骤16220中,基于云基础架构配置标准16320和在步骤16120发现的源基础架构配置和/或日志来映射基础架构配置。在步骤16230,映射来自(16330的)云和(16130的)源的基础架构管理的应用级别描述(例如,如本文其他处讨论的非功能需求的描述)。在可选的步骤16240,映射来自(16340的)云和(16140的)源的基础架构管理过程。
[0280]再一次,在一个或多个实施例中,比较和/或分析16200步骤可以涉及检查冲突。
[0281]参考步骤16340、16140和16240,实际管理过程的比较是可选的。特别地,如果执行例如到现有云的根本迁移,则典型地只有应用级别的描述需要被映射。关于步骤16120,在一个或多个实施例中,基础架构配置被发现,以映射到目标云中可能不同的软件(仅通过非限制的例子,与美国加州Pala Alto的惠普公司的产品相关的HP事件过滤器可被用于源环境,并且可被映射到可从美国纽约州Armonk的国际商业机器公司获得的可在目标环境中使用的IBM Tivoli Monitoring (ITM)事件过滤器)。关于步骤16130,可以从详细的发现(例如高可用性配置、计划停机时间和补丁管理设置)来导出通常由人工探访得到的若干个源方面。即使仍然通过人工探访来获取,如果结果是固定格式的,仍可以在步骤16230中考虑自动化分析。关于步骤16230,典型地必须达到或超过当前基础架构的应用级别描述,除非业务所有者明确同意更低的级别。
[0282]在替代的方法中,不是具有已给出的云描述,导出源环境的最合适的云描述可以是接洽(engagement)的一部分,例如,当整体目标是为企业构建合适的私有云时。
[0283]作为回顾和提供额外的细节,在执行任何IT迁移、变换、现代化等之前,可取的是分析要保留的组件和要使用的新组建之间的兼容性。这可以包括例如选择保留什么和改变什么,以及对要进行的更改进行分析以实现兼容性。
[0284]目前的迁移分析,特别是以定义良好的方法或甚至自动化的方式来执行的部分,集中在操作系统级别的兼容性,且有时集中在关键中间件例如应用服务器或数据库的兼容性。即,它们分析操作系统版本是否仍将在新的硬件上运行,或者数据库版本仍将在更新和相关的操作系统版本上运行。
[0285]随着云特别是托管基础架构即服务(MIaaS)云的出现,目前的迁移分析是不够的,因为这些云还规定了基础架构管理工具和过程,以及服务器的特定标准,其允许基础架构管理以标准的方式来运行。
[0286]一个或多个实施例有利地提供了一种用于基础架构管理方面主要是用于云迁移的自动化迁移分析的系统和方法。
[0287]一个或多个实施例有利地提供了一种用于基础架构管理分析的系统化和/或自动化方法。
[0288]分析基础架构管理迁移不同于分析中间件兼容性,因为重要的问题是源基础架构管理软件是否与云(特别是MIaaS)中的标准基础架构管理软件相冲突,并且需要被移除或修改(不同于源基础架构管理软件是否会在云操作系统上运行,这是在对中间件兼容性进行分析时需要分析的)。此外,与基础架构管理标准相关的其他设置需要被分析,例如假定的最小补丁级别。
[0289]在MIaaS云中,迁移意味着需要基础架构分析。一个或多个实施例有利地提供了对所需的基础架构更改进行系统分析、并将它们用于本文其他处描述的“快速迁移”过程的能力。[0290]现在参考图19,在某些情况中,示例性方法在两个阶段中执行。在第一阶段1902,要分析的元素特别是来自源系统的源基础架构客户端和服务器可被聚集并与客户(对源系统负责的所有者或有关方)一起讨论。例如,云服务提供者可以向用户表明需要卸载客户的所有“Vendor-X-patching系统”。在第二阶段1904,该决定被用于单独的源系统,且如果在第一阶段不可能有一般的决定,其可能被改进。
[0291]在一个或多个实施例中,相信检测冲突是可取的,所述冲突与第一阶段中的冲突管理相关。除非所有潜在基础架构软件的全面列表可用(如果编号为1901的阶段O已经可以很好地填充数据库1908并且客户的源环境中的所有软件已经在该数据库中,则会是这种情形),在此时分析整个软件列表以查看是否有这样的冲突,这是合适的。随着时间流逝,冲突和非冲突软件的上述数据库1909可以被发展。
[0292]在某些情况中,可以通过下列方式来进行源基础架构软件16110的发现:执行对要迁移的实际机器的发现,所述实际的机器包括该源基础架构软件的客户端(例如资产管理代理);检测该源基础架构软件的服务器(例如中央资产管理服务器);以及/或通过部署的基础架构工具的调查表。
[0293]于是,一个或多个实施例有利地提供了一种用于云迁移的管理基础架构分析的方法,包括:发现源基础架构中的基础架构组件;以及分析发现的基础架构组件与目标基础架构中的强制基础架构组件的冲突。
[0294]在某些情形下,基础架构组件包括一个或多个基础架构客户端、基础架构服务器、基础架构配置和基础架构过程。
[0295]在某些实施例中,冲突包括源基础架构组件管理强制目标基础架构组件会管理的相同的对象。
[0296]在某些情形下,冲突包括源基础架构组件使用与强制目标基础架构组件所使用的相同的资源特别是端口。
[0297]冲突的非限制示例包括下列的一种或多种:在客户端上当前缺少强制目标基础架构组件、存在不同版本的强制目标基础架构组件、以及存在具有可能不同配置的强制目标基础架构组件。
[0298]在某些实施例中,分析步骤的结果包括以下的一个或多个推荐:卸载基础架构组件、安装基础架构组件、修改基础架构组件的配置、从迁移中排除具有特定组件的服务器、或者与客户进一步讨论基础架构组件。此外在这方面,后两个结果特别会在以下情况下出现:源基础架构组件处于冲突中,但很可能还被用于管理不在云控制下的对象,例如,迁移到MIaaS云时的中间件。
[0299]在某些情形下,分析步骤分两个阶段执行;第一聚集阶段,其中,将所有发现的基础架构组件聚集并给予它们一般的推荐,以及第二每实例阶段,其中,推荐被应用于单个源系统并且在一般推荐未明确时被改善。
[0300]在至少某些实施例中,分析步骤可以包括配置比较和/或过程比较。
[0301]关于配置比较步骤16220,在某些情形下,对配置进行比较并对更改做出决策,这是可取的。如果基础架构软件被用于管理操作系统(OS )方面和应用方面两者,这尤其可取。例如,源服务器上的补丁软件可被设置以对OS以及数据库和web服务器打补丁。如果该源服务器被迁移至MIaaS云,则OS级别补丁需要被关闭以有利于云补丁软件,而数据库和web服务器补丁需要保持。另一方面,在其他情形下,源软件可被卸载,但服务器所有者会希望保留特定的策略,例如备份频率或监控事件的类型。
[0302]现在考虑如图17和18所示的客户仪表盘1707的方面。MIaaS迁移可能出现的相关对齐问题是集成到整个客户仪表盘中。例如,客户可以具有“CIO (首席信息官)仪表盘”,其给出了应用和服务器的状态的概览。在将某些服务器迁移到MIaaS之后,客户可能需要保持这种仪表盘,既因为仪表盘还显示应用,并且/或者因为不是所有服务器都被迁移,但客户想要对迁移和未迁移的服务器的联合概览。在这些情形下,应提供从MIaaS软件的报告特征到客户仪表盘的适配器。在图18中通过将仪表盘1707也连接到云提供的编号为1806的目标管理程序2来表示该方面。
[0303]现在将提供关于OS版本、补丁和安全性的相关观察。MIaaS云典型地规定的另一基础架构方面是精确的OS版本。对于OS,典型地适于决定容忍什么级别的偏差,以及在迁移之前什么可以自动更新。例如,可以决定是否容忍小版本偏差(例如V5.2而不是5.3),并且在小版本之间通常存在自动更新工具。考虑非版本OS类型,例如发布版(release)或版次(editions),也是合适的。
[0304]在某些情形下可能需要添加补丁。但是,如果发现具有在先版本(back-level)补丁的源服务器,不太可能存在针对某些较新补丁的应用问题。理想地,事先应当努力尝试从应用所有者发现这一点。在补丁升级之后典型地应该进行仔细的应用测试。
[0305]关于其他安全设置,有很多好的用于安全性的实践,例如不启用特定的服务和对特定OS文件的访问权限。应使源服务器符合这种需求。理想地,应用不要求相对于该最佳实践的现有偏差(例如,应用不应要求操作系统管理员密码仅6个字符长),但这也应当和应用所有者事先讨论。
[0306]在一个或多个实施例中,至少有两种重要的方法来决定针对操作系统设置等特别是安全相关的设置来改变什么:
[0307].与来自目录的干净云映像进行比较。在某些情形下,该方法可能有问题,因为在典型的操作系统中,应用级别和OS级别设置无法被干净地分离。例如,如果源映像在端口上具有服务而目录映像在该端口上不具有,典型地需要验证这是否是有用的应用服务。
[0308].与安全验证机制进行比较,如果云具有这样的机制的话,例如服务激活检查。典型地必须实现在这里验证的设置。但是,云中的这种测试可能不是完整的,因为云可能依赖于其目录映像的干净。
[0309]于是,在某些情形下,在上述两个阶段之前,可以存在一般的云迁移分析阶段,其中,决定那些安全设置是强制的。图19中编号为1901的阶段O描述了针对管理软件的一般云迁移分析;与其中描述的类似的方案也可被用于执行针对OS设置的一般云迁移分析。
[0310]应继续参考图16,且现在还应参考图17。图17示出了示例性源环境1702,发现和分析可在其中执行。环境1702包括具有编号为1701的管理程序I的服务器1703。环境1702还包括具有管理程序1706的服务器1704,该管理程序与数据存储1708中的日志和/或配置相接口。物理上,数据存储1708可以或可以不和管理程序1706在相同的虚拟或物理服务器上。即,配置1708还可以在服务器1704内部;但是,对于大的管理程序,配置数据库1708确实可以在别的地方(即在服务器1704外部)。
[0311]简便起见,图17中示出了两个管理程序;在典型的场景下,将存在长列表。管理程序1701、1706可以对应于例如“备份管理”和“合规管理”。
[0312]环境1702(在该例子中)还包括两个实例1709、1716。这些是与以本文别处讨论的快速迁移方法来迁移的那些实例类似的实例,即,它们可以是物理或虚拟的。服务器1703、1704原则上也可以是虚拟的,且它们中的一些可被迁移,从而在一种观点看它们也是实例。但是,一个或多个实施例解决了这样的情形,其中云(在图18的与管理区域1899中)具有其自己的管理程序,从而服务器1703、1704未被迁移。
[0313]环境1702包括管理程序1701、1706管理的一个或多个客户端1710、1713、1732。这些客户端例如可以位于实例1709、1716上,并且就它们与管理程序1701、1706的关系而言可以是客户端,而实例1709、1716还可以用作服务器,一个或多个应用1712、1714、1718、1720在其上运行。实例1709被管理程序1701、1706这两者管理,而实例1716仅被管理程序1706管理。这表明了每实例分析的合意性。
[0314]实例1709具有OS设置1711且实例1716具有OS设置1717。客户端1710具有配置文件1715 ;客户端1713具有配置文件1731 ;并且客户端1732具有配置文件1733。
[0315]在示出示例性目标(云)环境1802的图18中,假设编号为1701的管理程序I被保留(且由此其服务器以普通方式迁移到云生产区域中一见实例1803),而程序2被交换为云中(特别是在云管理区域1899中的服务器1804上)的相应程序1806。程序1806以和程序1706使用日志和配置1708类似的方式来利用日志和配置1808。
[0316]图18还示出了略微改变(安全性、补丁等)的OS设置;这是用与图17中的设置
1711、1717不同的编号1811、1817来示出的。实例1809与图17中的实例1709即实例1709的迁移版本类似;它包括具有配置1715的未更改的客户端1710,其由编号为1701的保留的管理程序I来管理。它还包括编号为1813的客户端,其具有配置1831、并且由编号1806的程序2来管理。实例1816与图17中的实例1716类似;它包括编号为1832的客户端2,其具有配置1833、并且由编号为1806的程序2来管理。应用1712、1714、1718、1720现在在目标环境1802中运行。
[0317]在某些情形下,代替保留程序1,或者作为程序3,相同的管理程序还可能已经在云管理区域中存在。于是相应的客户端可被保留,并且问题变成了“配置”是否还保持相同或者被更改到用于该“配置”的云标准。
[0318]图19示出了用于云迁移的管理基础架构分析中的示例性阶段。基本上存在编号为1901的准备阶段0,后面是两阶段的分析过程,包括编号为1902的阶段I和编号为1904的阶段2。在编号为1901的阶段0,在1905,仅基于云基础架构标准,进行抽象决策(例如,没有其他OS补丁管理软件可以运行“)。在1907,将抽象决策应用于某些众所周知的基础架构软件包。结果是管理客户端(版本)以及针对它们的一般决策的(至少部分)数据库1908 ;如下所解释的,数据库1908此后可被更新。
[0319]在编号为1902的阶段1,在1911,在每个实例上发现源基础架构客户端和服务器。在步骤1912,聚集发现的版本。在步骤1913,对每个管理客户端版本制定一个一般计划(匹配步骤210的一部分,但不是对每个源实例)。步骤1913获得来自步骤1905、1912和数据库1908的输入,并且也用其输出来更新数据库1908。步骤1913产生计划1914 ;可以理解,计划1914是说明性且非限制的。
[0320]在编号为1904的阶段2,进行每实例的决策。在可选的步骤1916中,如果在以后执行阶段2,在给定的实例(例如包含在示例性计划1914中提到的管理客户端1、2、5的实例)上重新发现基础架构客户端。如果未执行重新发现,这种知识仍可以从步骤1911得到。在步骤1917,将计划应用于这些实例。在非限制的例子中,决定卸载客户端1,保留客户端2。步骤1917由此获得来自可选步骤1916 (或者来自步骤1911)和来自计划1914的输入。在其中计划194表明“需要每实例决策”的步骤1918中,执行进一步的分析来决定(在非限制的例子中,针对客户端5来决定)。在可选的步骤1919中,进行到基础架构配置映射(如在步骤220那样)。在该例子中,这可能针对客户端2和5来执行。
[0321]图20示出了用于关于冲突的决策的可能的用户接口,特别是用于阶段O (步骤1907)或阶段I (步骤1913),其中进行用于特定管理软件类型的一般推荐。在2002,查询在“Middleware Name”(中间件名称)字段输入的管理软件是否与云SCE+版本1.5中的任何软件冲突。在2004示出了响应:在该情形下,确实存在冲突,并且给出了冲突类型的解释。在另一用法中,可以(在视图2002的最底下的输入字段中)输入特定的软件所运行的端口,以检查端口冲突。
[0322]下列SQL代码片段是可用于阶段2 (步骤1917)中的决策的代码的简化版本。假设在源实例中安装的软件(管理软件和应用)被汇聚在表“MIDDLEWARE_INSTALL_MASTER”中,此外,假设组件1908被实现为数据库表“MW_MANAGEMENT_L00PUP”,其中为简单起见,假设具有任何冲突的一切都被卸载,并且具有已知冲突的软件准确地汇集在在该表中。要做出的适当的决策是,基于中间件是否出现在第二张表中,是否针对前一张表中的每一行来卸载。下列查询这么做,并假设决策进入前一张表的“FUNCTION” 一列。
[0323]
【权利要求】
1.一种方法,包括: 将至少一个目标虚拟盘描述符与至少一个源虚拟盘描述符合并,该目标虚拟盘描述符描述与目标虚拟化环境中的现有目标虚拟机关联的至少一块虚拟盘,该源虚拟盘描述符描述与源关联的至少一块虚拟盘,以获取和所述目标虚拟化环境兼容的至少一个合并的虚拟盘描述符;以及 根据所述至少一个合并的虚拟盘描述符,用与所述源关联的所述至少一块虚拟盘来替换与所述目标虚拟化环境中的所述现有目标虚拟机关联的所述至少一块虚拟盘。
2.如权利要求1所述的方法,其中,在所述合并和替换步骤中,所述虚拟化环境包括目标云环境。
3.如权利要求2所述的方法,其中: 所述源包括在所述目标云环境外部的客户源;并且 所述替换包括将与所述源关联的所述至少一块虚拟盘迁移到与所述现有目标虚拟机关联的所述至少一块虚拟盘。
4.如权利要求3所述的方法,还包括比较以下两者的虚拟资源: 与所述现有目标虚拟机关联的至少一块虚拟盘;以及 与所述目标云环境外部的所述客户源关联的所述至少一块虚拟盘; 其中,所述合并响应于所述虚拟资源的所述比较表明其兼容性。
5.如权利要求4所述·的方法,还包括检查所述合并步骤的成功,其中,所述替换是响应于所述检查表明所述合并步骤的所述成功。
6.如权利要求3所述的方法,还包括针对至少一个额外的源虚拟盘来重复所述合并和替换步骤。
7.如权利要求6所述的方法,还包括更新整体实例描述符。
8.如权利要求1所述的方法,其中,所述合并包括: 检查与所述至少一个源虚拟盘描述符关联的至少一个源属性; 检查与所述至少一个目标虚拟盘描述符关联的至少一个目标属性;以及将多个合并规则应用于所述至少一个源属性和所述至少一个目标属性,以获取所述至少一个合并的虚拟盘描述符; 其中,所述合并规则在所述至少一个合并的虚拟盘描述符中持久化源属性和目标属性,所述源属性是确保所述目标虚拟化环境中继续的虚拟机运行所需的,且所述目标属性是所述目标虚拟化环境成功地采用所述虚拟机所需的。
9.如权利要求8所述的方法,其中,在所述应用步骤中,所述合并规则包括: 持久化与所述源关联的所述至少一块虚拟盘的虚拟盘输入-输出控制器; 持久化与所述源关联的所述至少一块虚拟盘的块大小和块数量; 持久化与所述现有目标虚拟机关联的所述至少一块虚拟盘的虚拟盘唯一描述符。
10.如权利要求1所述的方法,还包括转换源实例以获取源盘映像。
11.如权利要求1所述的方法,其中: 所述目标虚拟机具有目标虚拟机配置; 所述目标虚拟机被容纳在目标管理程序上;并且 在所述合并步骤中,与所述目标虚拟化环境的所述兼容性至少包括与所述目标虚拟机配置和所述目标管理程序的兼容性。
12.如权利要求11所述的方法,其中,所述目标虚拟机具有目标操作系统;并且其中,与所述目标虚拟化环境的所述兼容性还包括与所述目标操作系统的兼容性。
13.如权利要求1所述的方法,其中: 所述源包括备份源;并且 所述替换包括使用与所述备份源关联的至少一个盘映像来恢复与所述现有目标虚拟机关联的所述至少一块盘。
14.如权利要求1所述的方法,其中,在用与所述源关联的所述至少一块虚拟盘来替换与所述目标虚拟环境中的所述现有虚拟机关联的所述至少一块虚拟盘时,在所述替换之前和之后维护所述现有目标虚拟机的唯一描述符。
15.如权利要求1所述的方法,还包括提供一种系统,其中,所述系统包括单独的软件模块,每个单独的软件模块在计算机可读的存储介质中实现,并且其中,所述单独的软件模块包括 MergeDiskMetaData 模块和 PutDisk 模块; 其中 由在至少一个硬件处理器上执行的所述MergeDiskMetaData模块来执行所述合并;并且; 由在至少一个硬件处理器上执行的所述PutDisk模块来执行所述替换。
16.一种系统 ,该系统包括装置,其被配置为执行如权利要求1到15中的任何一个所述的方法步骤。
【文档编号】H04L29/08GK103853595SQ201310626100
【公开日】2014年6月11日 申请日期:2013年11月28日 优先权日:2012年11月29日
【发明者】M·A·博尼拉, F·格拉夫, D·科恩, B·彼得森, B·M·普费茨曼, J·J·罗弗拉诺, K·J·舒尔茨, C·C·扬, 章晓兰 申请人:国际商业机器公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1