《VMware vCAT权威指南:成功构建云环境的核心技术和方法》一3.7 编排和扩展-阿里云开发者社区

开发者社区> 华章出版社> 正文
登录阅读全文

《VMware vCAT权威指南:成功构建云环境的核心技术和方法》一3.7 编排和扩展

简介:

本节书摘来自华章出版社《VMware vCAT权威指南:成功构建云环境的核心技术和方法》一书中的第3章,第3.7节,作(美)VMware vCAT 团队,更多章节内容可以访问云栖社区“华章计算机”公众号查看

3.7 编排和扩展

vCloud环境由多种可暴露Web服务的组件组成。vCloud编排(Orchestration)平台可以将这些服务联系在一起,组成一个合乎逻辑的工作流。VMware有支持工作流程定义和执行的不同管理应用程序。
vCloud Orchestrator是vCenter中的一个技术性编排创作平台,管理员可以创建利用VMware和第三方vCloud组件广泛集成的工作流,自动化重复性任务。编排工作流的详细例子参见第7章。
vFabric Application Director自动化部署多层应用到vCloud。vFabric Application Director可以通过提供用于在虚拟机上安装、配置和启动软件服务的服务目录,简化虚拟机模板管理。vFabric Application Director使用vCloud API向vCloud提供者发出配置请求,可以部署于公共、私有和混合vCloud环境中。
VMware Service ManagerTM是一个可配置的ITIL平台,具备服务桌面、自动化配置和更改管理、IT资产管理、自助服务和服务请求功能。作为服务请求的一部分,它支持一个可配置门户,使用高级业务工作流建模完成批准、通知和任务集成。

3.7.1 vCloud API

vCloud API为管理vCloud实例中的资源提供了一个接口,是联盟和生态系统支持的基石。当前所有的联盟工具都通过vCloud API与vCloud环境通信。重要的是,vCloud环境向vCloud消费者暴露vCloud API。
vCloud API可以用于简化使用vCloud Director Web控制台之外的用户界面与vCloud资源的通信。例如,用vCloud API配置门户与vCloud Director通信。
目前,vCloud Director是暴露vCloud API的唯一软件包。在某些环境中,vCloud Director处于另一个门户之后,或者处于vCloud消费者无法访问的位置。在这种情况下,使用一个API代理或者中继,将vCloud API暴露给最终消费者。
因为vCloud API的价值,有些环境可能希望对API的使用进行计量和收费。VMware也建议通过审计跟踪和API检查保护vCloud API。在某些情况下,vCloud提供者可能打算用新功能扩展vCloud API。
为了对vCloud API用例提供帮助,vCloud提供者可能希望实现一个API代理。vCloud API是基于REST的服务,包含了XML载荷。因此,任何合适的XML网关都可以用作vCloud API代理。当今市场上有多种擅长XML网关服务的第三方解决方案。VMware与某些这类供应商协作,开发了如何在vCloud Director环境中部署它们的解决方案的联合指南。关于这些努力和协作的最新信息,可以联系当地的VMware vCloud专家。
关于vCloud API和SDKs的更多信息,可访问开发人员社区:http://communities.vmware.com/community/vmtn/developer/forums/vcloudapi

3.7.2 使用vFabric Application Director进行云配置

vFabric Application Director是进入vCloud创建和部署多层应用程序的入口点。vFabric Application Director通过定义一个与vCloud Director组织及相关目录关联的vCloud提供者,消费vCloud资源。
vFabric Application Director使用vCloud API,需要访问到vCloud Director服务器以发出配置请求。
vFabric Application Director有一个服务目录,定义如何在虚拟机上安装、配置和启动服务。
vFabric Application Director可以将虚拟机和服务组装为一个部署到vCloud提供者的多层应用程序。

3.7.2.1 简化vApp模板管理

可以为每个正常安装到部署于vCloud环境的虚拟机上的软件组件构造目录服务。虚拟机可以看作运行于客户机操作系统上的一组软件包和服务。大部分软件组件适合于层次模型,这种模型的管理职责可能落到在不同部门身上,因为每年每个层次的软件都需要维护。
在图3.39中,软件和服务的多个层次定义虚拟机的特性。通过在vFabric Application Director目录中为每个组件创建服务,每个部门可以在目录中维护一个服务组件。这简化了基础虚拟机模板的创建和管理过程,因为模板只需要更包含基本操作系统和合适的补丁级别。所有其他服务可以由vFabric Application Director安装、配置和启动。

3.7.2.2 简化vApp模板管理

为了构建一个多层vApp,vFabric Application Director使用一个蓝图,以构建包含多个虚拟机的vCloud vApp。vApp中的每个虚拟机可以基于不同的vApp模板,每个虚拟机可以由从vFabric Application Director目录中选择的服务自定义。
在图3.40中,一个由表示层(Web)、应用程序层和数据库层组成的三层应用在vFabric Application Director中建立蓝图模型。在部署时,vFabric Application Director根据蓝图中指定的虚拟机模板,在vCloud提供者中创建对应的vApp。

image

3.7.2.3 客户自定义和vFabric Application Director代理

vFabric Application Director消费的虚拟机模板必须安装vFabric Application Director代理。交互工作如下:
1.在第一次启动时,虚拟机由vFabric Application Director在vCloud提供者环境中,通过vCloud客户自定义过程部署。
2.在客户自定义结束时,部署的每个虚拟机上的vFabric Application Director代理初始化与vFabric Application Director服务器的联系,并下载最新版本的代理软件。
3.代理下载服务脚本并创建环境变量,其对应于服务或者蓝图中创建的属性。
4.然后,服务脚本可以运行,在部署的每台虚拟机上安装、配置和启动软件。
每台虚拟机中的vFabric Application Director代理建立与vFabric Application Director服务器的连接。这降低了防火墙管理的复杂度。

3.7.2.4 vCloud网络和vFabric Application Director

配置vApp时,vFabric Application Director不创建任何vApp内部网络。Application Director将置备好的vApp直接连接到vCloud组织虚拟数据中心网络。这移除了vFabric Application Director配置保护式vApp的能力。属性可以在开发时动态更新,所以可以编写服务脚本,为安装或者配置的软件修改相关的配置参数。
举个例子,可以创建一个属性,在部署时获取新虚拟机的IP地址。服务脚本可以使用这个IP地址属性,基于新置备虚拟机的新IP地址配置应用程序。这个属性可以输出到多个服务,并通过蓝图中的依赖映射,输出给多个由vFabric Application Director部署的虚拟机。
vFabric Application Director部署的vApp如果直接连接到组织虚拟数据中心,必须允许每个虚拟机的代理服务与vFabric Application Director服务器联系。
vFabric Application Director不将vApp连接到隔离的组织虚拟数据中心网络,因为这样会消除代理与vFabric Application Director服务器联系的能力。
vFabric Application Director只将vApp连接到直连或者路由到外部网络的组织虚拟数据中心网络。

3.7.2.5 构建软件存储库

构建一个中心软件存储库或者仓库简化了服务部署过程。将软件存储库放置在由vFabric Application Director配置的应用程序所部署的目标vCloud提供者所在的同一个环境或者数据中心。
在复杂的部署中,从软件存储库下载的数据可能很大,所以要考虑软件存储库和置备的虚拟机之间的带宽和延迟。
vFabric Application Director可以选择用特定的内容类型属性,将内容放在置备的虚拟机上。为了支持这一功能,软件存储库必须允许文件下载的HTTP访问。其他从软件存储库读取数据的访问方法需要服务创作者自己编写。

3.7.2.6 设计的影响

vFabric Application Director服务器只在部署到基于vCloud Director的环境中时得到支持。vFabric Application Director所在的vCloud环境往往是应用程序置备的相同环境,因为vFabric Application Director使用vCloud API发出置备请求,vFabric Application Director服务器必须能够向管理vCloud环境的vCloud Director发送API调用。这对于某些消费者的安全性有如下影响:
在公共vCloud部署中,vCloud消费者往往只能访问一个vCloud组织。在这种情况下,vFabric Application Director vCloud提供者组织与存放vFabric Application Director服务器的组织相同。如果可以访问多个组织,将vFabric Application Director服务器和软件存储库部署到一个组织,将置备的工作负载部署到另一个组织更为有利。从部署的虚拟机到vFabric Application Director和软件存储库必须具备网络访问能力。
在私有vCloud部署中,将vFabric Application Director服务器部署到指派为管理系统的vCloud环境中。这为管理目的提供了隔离,可以简化Chargeback的管理。软件存储库也可以部署到管理组织中。vCloud提供者可以在vFabric Application Director中根据组织隔离策略定义。从部署的虚拟机到vFabric Application Director和软件存储库必须具备网络访问能力。
在混合vCloud部署中,vFabric Application Director服务器对于部署应用的vCloud提供者来说可能不在本地。vFabric Application Director使用vCloud API向vCloud提供者发出置备请求。安装在每个vFabric Application Director置备虚拟机上的代理也必须能够建立到vFabric Application Director服务器的连接。VMware建议将软件存储库放在目标vCloud提供者的同一个环境或者数据中心,这是因为带宽和延迟的考虑。
将vFabric Application Director服务器部署到vSphrere环境的配置目前不受支持。

3.7.3 vCloud消息

vCloud消息提供将vCloud Director与外部系统连接的能力(见图3.41)。vCloud Director可以配置为向基于AMQP的企业消息代理发送通知或者消息。vCloud消息通过无阻塞和阻塞通知提供可见性,允许端到端的集成。

image

3.7.3.1 消息发布

系统管理员可以配置vCloud Director,启用所有事件通知或者特定阻塞任务的消息发布:
通知在用户发起事件(例如,vApp的创建、部署和删除)以及系统发起事件(例如,vApp租约到期)时发起,包含对应vCloud Director实体的新状态。
阻塞式任务在发布消息之前挂起长时间运行操作(作为任务启动),并等待系统管理员批准或者拒绝请求。
对于vCloud Director UI或者vCloud API中启动的操作启用消息发布。
vCloud Director向高级消息队列协议(Advanced Message Queuing Protocol,AMQP)交换发布消息(需要由vFabric RabbitMQ版本2.0支持的AMQP版本0.9.1及更高版本)。

3.7.3.2 路由

AMQP代理将路由用作过滤vCloud通知消息和将它们发送到用于一个或者多个扩展的不同队列的有效手段。
根据队列路由键值和交换类型,消息交换将通知路由到所绑定的队列。vCloud通知消息路由键值采用如下语法格式:
<操作成功标志>.<实体UUID>.<组织UUID>.<用户UUID>.<子类型1>.<子类型2>…<子类型N>.[任务名称]

3.7.3.3 扩展

扩展是一个脚本或者应用,具有如下功能:
订阅一个AMQP队列,接收新消息。
鉴别接收到的消息。
将消息处理为操作(内部或者外部调用)。
调用vCloud API获取涉及操作的对象的更多信息,并对阻塞的任务采取措施。

3.7.3.4 设计考虑因素

如下考虑因素适用于通知和阻塞任务:
通知和阻塞任务是独立的机制,在同一个AMQP总线上实现。
当一个任务被阻塞,由一个扩展来负责发送消息查询相关对象的状态,或者对阻塞的任务采取措施。
对阻塞任务进行的有效调用有Resume、Progress、Abort和Continue。
在vCloud Director中为阻塞任务配置全局超时。
你可以从VMware vCloud Director UI直接终止等待的阻塞任务。

3.7.4 vCenter Orchestrator

vCenter Orchestrator是用于组装操作性工作流的一个系统(见图3.42)。vCenter Orchestrator的主要好处是协调多个系统,实现其他情况下需要在不同系统上进行多个单独操作的复合操作。编排工作流的详细示例参见第2章。

image

一般来说,如果一个操作只使用一个底层系统,可以考虑提供对该系统的直接访问,以提高效率、降低复杂度。在vCloud环境中,vCenter Orchestrator可以自动化高度重复性的任务,避免手工操作和错误。
vCenter Orchestrator由如下应用程序组成。
vCenter Orchestrator Client:使工作流开发人员能够创建、组装、测试和打包工作流、操作、策略、资源和配置。
vCenter Orchestrator Server Web Configuration:作为单独应用程序肩并肩地和Web前端一起运行,使管理员能够配置vCenter Orchestrator服务器及其插件,并执行维护操作。
vCenter Orchestrator Server:提供运行时编排服务,包括接口和可插拔适配器。
vCenter Orchestrator有一个插件框架,以及可用于vCenter Server、vCloud Director和vCenter Chargeback的插件。这使得vCenter可以在VIM API、VIX API、vCloud API和Chargeback API级别上编排工作流。
编排用例包括:
vCloud管理操作
组织管理操作
组织消费者操作

3.7.4.1 设计考虑因素

根据总体架构和编排的使用方式,编排一个vCloud可能需要一个或者多个vCenter Orchestrator服务器。vCenter Orchestrator通过使用它们的Web服务管理vCloud Director和vCenter。
按照插件,vCenter Orchestrator可以管理不同数量的主机。实际的限制取决于一些决定因素,例如带宽、对象数量和并发工作流。例如,单个vCenter Orchestrator可以管理:
多个vCloud Director主机
多个vCenter主机
多种其他主机类型(UCSM、REST、SOAP、vCenter Update Manager)
为指定版本设计的插件适用于同一个版本的产品。如果管理混合的主机版本,将插件版本保持在最早的公共版本,以提供向后兼容性(例如,如果管理vCloud Director 1.5和vCloud Director 5.1的混合环境,则使用1.5插件)。在可能的情况下避免混合主机版本——如果混合了各个版本,操作必须进行全面的测试。使用插件的最新版本并不能支持产品的旧版本。
多个vCenter Orchestrator服务器可以管理:
同一个vCloud Director主机(或者负载平衡单元)
同一个vCenter服务器
vCloud Director使用无状态的REST风格Web服务。在vCloud Director和vCenter Orchestrator之间没有维护任何会话——这最小化了两个服务器的资源使用。当需要更新时(例如,用vCloud Director对象启动一个工作流时),使用的资源和更新的对象数量成正比。这一过程包括向vCloud Director服务器发送多个HTTP GET/PUT/POST/DELETE请求,并根据响应创建或者更新vCenter Orchestrator中的对象。使用多会话(在插件配置中的per user模式)倍增了对象的数量。vCloud Director可以实施负载平衡,以避免单故障点和在单一单元上使用过多资源。
vCenter使用一个有状态的SOAP Web服务,支持大服务定义和高级机制,例如vCenter Orchestrator广泛使用的通知服务。vCenter和vCenter Orchestrator之间持续地维护会话。这对两个服务器上的资源消耗有重大影响,甚至在没有工作流活动时也是如此。
会话活动和两个服务器上的相关资源消耗与vCenter Orchestrator vCenter库存中加载的对象数量与打开的会话数量的乘积成正比。因此,配置vCenter插件,用共享会话代替每用户会话,并限制管理单个vCenter的vCenter Orchestrator数量。工作流活动还会因为不在库存缓存中的对象而消耗资源。
其他考虑因素包括:
vCenter Orchestrator 5.1 引入了每节点20个vCenter Server实例、1280台vSPhere主机和最多35?000个虚拟机的库存最大限值。
vCenter Orchestrator可伸缩性可以用VMware vCenter Orchestrator Multi-Node(多节点)插件提升。更多的信息参见Multi-Node插件博客(http://blogs.vmware.com/orchestrator/2012/01/vco-multi-node-plug-in.html)。
如果vCenter Orchestrator因为需要管理大量对象而超载,尝试调整服务器以获得更大的伸缩性。作为替代,设计解决方案使用不同的vCenter Orchestrator实例来管理不同的vCenter Server,或者用不同的vCenter Orchestrator实例连接到一个大的vCenter,并配置多个账户来访问不同vCenter区域。

3.7.4.2 可伸缩性

在配置vCenter Orchestrator运行大量并发工作流时,理解编排引擎的工作原理是很有必要的。
vCenter Orchestrator工作流引擎默认配置允许运行多达300个并发工作流。当运行队列超出这个数字,工作流被放入一个执行队列,并在一个或者多个工作流执行完成之后移回运行队列。完成的工作流状态可能是完全成功、失败、取消或者“钝化”(等待信号状态)。执行队列默认大小是10?000个工作流。如果执行队列超过这一尺寸,工作流引擎将后续的工作流标记为失败。
运行的工作流消费至少一个运行线程(运行工作流、或者更新工作流状态)以及1MB到几个MB的内存(根据启用插件和插件对象的数量而定)。限制工作流数量可以保证线程和内存的分配,最大值取决于JVM设置、操作系统和底层硬件。
要修改默认值,可以在Orchestratorappserverservervmoconfvmo.properties配置文件中修改如下属性:
com.vmware.vco.workflow-engine.executors-count
com.vmware.vco.workflow-engine.executors-max-queue-size
VMware建议在增加并发工作流默认数量之前遵循本章剩余部分中的方针,因为这样做需要扩展vCenter Orchestrator Java虚拟机、主机操作系统、主机虚拟机的资源,还有可能需要扩展vCenter Orchestrator数据库。
每个活动插件都会影响工作流引擎性能。插件加载类、运行更新线程、将信息记录到磁盘、向脚本引擎提供对象并维护库存。即使不使用插件,它也会消耗资源并增加每个运行工作流的内存足迹。禁用所有不在用的插件可以增加工作流引擎的容量。

3.7.4.3 工作流设计

工作流设计影响资源的持久性和使用。下面是工作流设计的原则。
高效脚本:使用脚本开发设计原则,以避免不必要和高资源需求的操作,如活动等待循环、在相同资源上重复进行开销巨大的调用和低效的算法。在vCenter Orchestrator测试服务器上进行大量测试,然后再在生产系统上运行新的或者更新后的工作流。
工作流线程控制:运行许多不同的工作流会增加使用的资源数量。
单独启动的工作流、使用异步工作流或嵌套工作流调色板元素启动的工作流运行于不同的工作流实例。
主工作流中的一个子工作流仍然运行于同一个工作流实例,但是使用的资源较少。在较高级的工作流中链接工作流,而不是顺序调用单独工作流。
减少等待工作流的数量:如果高并发性的原因是大量工作流在外部系统上等待,如下的方法有助于避免在等待时消耗资源。
Wait Until(等待到某一时间)工作流调色板元素和System.Sleep()方法保持了执行队列中工作流的运行状态。即使线程处于Sleep(休眠)模式,它仍然会消耗内存。对于长期运行的工作流,这些元素和方法可以由waiting timer(等待计时器)或者waiting event(等待事件)调色板元素代替。使用这些元素钝化工作流执行,并将其状态保存在vCenter Orchestrator数据库。然后,该工作流从运行队列中被删除,内存被释放。vCloud Director库长时间运行的工作流会大量使用等待事件调色板元素。
当工作流活动必须挂起一段确定的时间时,可以编程调度工作流任务。
尽管钝化节约活动资源,但是每次钝化和激活都要消耗CPU资源和数据库访问。下面是使用等待计时器或者等待事件的设计原则:
不要同时触发大量这类活动。
不要在循环中设置非常短的计时器。

3.7.4.4 解决方案原则

除了服务器配置和工作流设置之外,你必须有一个严格控制的总体解决方案,包括上级管理层和经过编排的系统。
误用编排:编排引擎为管理复杂的跨领域处理提供了自动化和集成。它为通用型、弹性和审核提供了多种机制,这些机制对于不需要这种服务水平的简单操作来说显得多余了。不要使用vCenter Orchestrator代替对vCloud Director API的单独调用。
工作流控制:调用vCenter Orchestrator的系统应该有根据vCenter Orchestrator测试的最大限值进行调整的工作流管控机制,以避免资源过度消耗。
负载平衡:如果超过了最大限值,可能有必要设计跨越不同vCenter Orchestrator服务器的工作流负载平衡系统。
被编排系统的瓶颈:使用vCenter Orchestrator工作流避免同时在被编排系统上启动太多操作。设计这种逻辑以支持所定义的负载。将影响启动工作负载的参数暴露为配置元素,由编排管理员进行调整(确定并行处理的vApp克隆数量的参数)。

3.7.4.5 Orchestrator Client

vCenter Orchestrator有一个客户端应用程序,可以开发工作流和操作。在服务器安装期间,在服务器的同一个系统上安装客户端。在生产环境中,客户端软件的本地安装只用于匹配的客户端无法通过开发人员工作站访问的紧急情况下。
让开发人员在他们的工作站上安装客户端,以连接到同一个LAN上的测试或者开发服务器。如果连接到远程服务器,可以使用远程桌面,从同一个LAN运行客户端。

3.7.4.6 vCloud Director插件

在指定插件的Host(主机)字段时,该值必须与vCloud Director服务器指定的相同。该值按照如下方式确定:
如果在vCloud Director Administration(管理)——Public Addresses(公共地址)——External REST API Base URI(外部REST API基本URI)中指定了一个值,在插件配置中就要使用该值。例如,使用负载平衡,vCloud Director要求将公共地址更改为负载平衡器配置中的虚拟服务器指定的地址。判定正向和反向DNS适用于指定的地址。
如果指定了主机名或者完全限定域名(FQDN),验证正向和反向DNS有效,并在插件配置中使用FQDN。
如果没有指定主机名,且vCloud Director服务器被配置为只使用一个IP地址,在插件配置中使用同一个IP地址。
如果不按照规定配置插件,就会导致不良的后果。
在指定Host字段之后,为用户登录管理选择一个策略。可用选项是Share a Unique Session(共享唯一会话)和Session Per User(每用户会话)。
配置Share a Unique Session时,根据配置的组织和凭据,在vCenter Orchestrator和vCloud Director之间创建单一会话。vCenter Orchestrator用户继承那些凭据在任何执行工作流上的权限。从审计的角度看,共享会话将审核的责任从vCloud Director转移到vCenter Orchestrator。为这种集成开发的工作流必须有合适的日志级别,以符合组织的审核要求。
配置Session Per User时,vCenter Orchestrator中验证的用户用于vCloud Director中的身份验证。这为每个用户创建一个vCenter Orchestrator和vCloud Director之间的会话,该会话与基于这个用户角色和权限的库存关联。这要求组织使用与vCenter Orchestrator中配置的LDAP主机同步的LDAP主机。
还要考虑如下因素:
对于使用不同LDAP主机的组织,每个组织需要一个专用的vCenter Orchestrator实例。
多个会话可能会耗尽CPU、内存和带宽。
此外,需要一个组织设置。组织定义vCenter Orchestrator可以执行的操作范围:
在需要对所有组织及其相关的虚拟基础架构资源的创建、读取、更新和删除权限时,设置为SYSTEM。
在将创建、读取、更新和删除权限限制在属于指定组织的所有元素时,设置为具体的组织。
插件的最常见用例通常对应于如下场景之一。
公共或者私有vCloud提供者将vCenter Orchestrator用作vCloud管理群集的一部分:
管理提供者资源和启动新组织需要对vCloud Director的系统级管理权限。这种场景使用Share a Unique Session,将组织设置为SYSTEM,并使用系统管理员凭据。
如果管理任务需要不同角色和权限,使用Session Per User。在这种情况下,SYSTEM组织必须设置为与vCenter Orchestrator配置的vCloud提供者LDAP主机同步。
如果配置多于一个vCloud Director连接,则使用共享会话和每用户会话的组合,授予vCenter Orchestrator工作流用户对配置组织的共享访问会话权限。例如,如果插件用系统共享会话设置且存在授予给定组织的vCenter Orchestrator用户权限的需求,则让两个连接都使用Session Per User,并为不同的会话设置不同的权限,以避免所有用户对所有组织有广泛的访问权限。
作为一个或者多个组织的公共vCloud租户,在租户场内使用vCenter Orchestrator或者将其作为组织vApp的一部分:
对于组织管理任务,使用Share a Unique Session和组织管理员凭据。如果管理超过一个组织,可以为每个组织添加一个新的vCloud Director连接。
将插件配置为Session Per User,将没有包含在vCloud Director界面中的工作流操作任务委托给具有不同角色和权限的组织用户。在这个配置中,将组织设置为与vCenter Orchestrator中配置的租户LDAP主机同步。
作为一个私有vCloud组织租户,使用一个vCenter Orchestrator作为vCloud管理群集的一部分,还使用一个单独的LDAP主机。
vCloud提供者用这个特殊的组织和Session Per User配置一个新连接。将组织设置为与vCenter Orchestrator配置的LDAP主机同步。在其他连接中配置的所有其他组织也与同一台LDAP主服务器同步。

3.7.5 vCenter Orchestrator示例

编排为vCloud管理、组织管理和自助服务消费者操作带来了自动化能力。

3.7.5.1 vCloud管理编排示例

下面的示例凸显了vCenter Orchestrator对vCloud系统管理员的价值。下面的用例专注于基础架构管理和资源配置过程。
提供者希望从一位新客户开始工作,主要的步骤是添加一个新组织、用户(可能来自LDAP)、网络、虚拟数据中心和目录,该提供者可能还想计划一个定期的成本分摊报告,用于记账和向租户发送电子邮件通知,告诉他们vCloud环境已经就绪。
租户请求附加的外部网络容量。提供者系统自动化网络创建,这包括名称生成、标识和可用VLAN和IP地址段的分配;网络交换机和vCloud边界防火墙的配置;vCenter中外部网络的创建,以及向租户组织分配的外部网络。

3.7.5.2 组织管理编排示例

租户组织中的运营任务也可以从自动化中获益。下列例子处理vApp生命周期管理,如vApp创建、配置、维护和退役。
在使用活动目录的环境中创建虚拟机以标识服务如验证和打印服务。在部署之后,虚拟机必须加入活动目录域。使用组织单元(OU)而非默认的计算机容器通常是首选的方法。vCenter Orchestrator可以在虚拟机部署之前,于恰当的OU中创建虚拟机的计算机账户,以便使计算机账户名称保持唯一,且存在于恰当的OU中。类似地,当虚拟机退役时,vCenter Orchestrator可以删除OU中的条目,作为同一工作流的一部分。
组织管理员希望在一次操作中,管理跨越多个虚拟机的软件包或者配置元素的重复更新。工作流可以接受一个系统列表和一个软件或者配置源作为参数,然后在每个系统上执行更新。

3.7.5.3 vCloud消费者操作编排示例

vCloud消费者操作是组织管理员希望卸载到一个自助服务操作的任务。将操作当作一个vCenter Orchestrator工作流来执行,提供了通过内建门户或者利用Web服务API定制的门户,将操作输出给客户的简易方法。许多这类操作可以直接通过vCloud Director Web控制台完成。但是,有些操作影响多个系统或者更适合于客户门户。这些操作是编排工作流的自然候选。vCloud消费者对编排组件没有可见性,所以vCloud提供者必须用vCenter Orchestrator Client初始化工作流,除非提供者创建一个门户作为vCenter Orchestrator的前端。
示范用例包括用VIX插件在虚拟机上重置账户密码,将负载平衡的服务置于维护模式(停止服务、将其从负载平衡池删除并禁用监视器),将证书加载到虚拟机以及从组织目录中部署自定义应用程序的实例。
vCenter Orchestrator可以用于在vCloud API和vSphere级别上创建自定义工作流。其他vCloud配置解决方案通常有内建的工作流功能,这些功能通过vCloud API与vCloud Director集成,是vCenter Orchestrator的替代品。
安装、配置和工作流部署的更多信息参见VMware vCenter Orchestrator文档(www.vmware.com/support/pubs/orchestrator_pubs.html)。编排工作流的详细例子也可以参见第2章。

3.7.5.4 使用Orchestrator作为vCloud Director的扩展

vCenter Orchestrator完全支持通过vCloud Director、AQMP和其他特殊产品插件,消费阻塞任务和通知消息、回调和对外部系统的调用(如图3.43)。

image

AMQP插件和工作流一起提供,需要一次性安装。它提供了如下价值。
添加一个代理:通过提供主机名和凭据添加一个AMQP代理。
声明一个交换:为配置的代理声明一个交换。
声明一个队列:为vCenter Orchestrator工作流声明一个队列。
绑定:提供一个路由键值,将一个队列绑定到交换。
订阅队列:允许vCenter Orchestrator接收新消息更新。
重启vCenter Orchestrator服务器将自动保存和重新加载配置。
插件支持添加subscription类型的策略元素,这类元素有一个onMessage触发事件。可以建立一个策略,启动一个工作流处理新消息。
为筛选和处理消息提供工作流,以输出vCloud Director对象。这些工作流可以为审核和调用外部系统之前设计自定义逻辑提供所有必要的信息。外部系统的调用有两种方式:
特定的vCenter Orchestrator插件适配器,如vCloud Director、vCenter、Update Manager和活动目录。
通用插件适配器,如REST、SOAP、XML、SSH和JDBC。
vCloud Director工作流可以终止、恢复消费阻塞任务对象或者使其失败。使用vCloud消息的工作流示例参见第4章。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

华章出版社

官方博客
官网链接