🔦2x09 一起来描绘vRealize Automation的复合蓝图

前不久，晓冬出差杭州，参与了一个VMware私有云的建设项目。利用VMware vRealize Automation实现对包括vSphere计算、NSX DataCenter网络与安全以及vSAN超融合存储组成的基础架构平台的统一调度，并提供应用和服务的快速交付。

客户对于VMware SDDC解决方案是非常信赖的，在结束本实施阶段的里程碑任务后，用户非常想了解vRealize Automation（后文简称vRA）的复合蓝图是如何勾勒的，晓冬也正好乘此机会，做一个简单的科普。

注意：虽然vRA8.0.1已经发布，但是这个客户依旧采用vRA7.6版本。因此，本篇分享将围绕7.6版本的框架和概念进行叙述。

在此，特别感谢VMware的苏旭和陈少勇两位大神，在我学习vRealize Suite相关产品期间，给予的指导与帮助。

0x01.基本概念

“蓝图”是一个相对抽象的概念，为了更好地说明问题，我们先来聊聊什么是vRA的租户、架构组、业务组和各类管理员吧。

为了便于理解，我们用一些比喻来描述上面这张图的几个概念。

对于企业来说，想要稳定高效地运作业务，需要有一个良好的基础架构环境，其中包括了物理服务器这类计算资源、以及网络设备、安全设备等。就好比是一个住宅小区，为了容纳居民入住，就一定要有配套的基础设施，比如强弱电、各类管道、混凝土结构的一幢幢居民楼等。

为了更好地实现管理，会有小区物业负责维护这些基础设施，提供给入住的居民使用，这就是“基础架构管理员”角色的职责。任何基础架构范畴的维护，都交给基础架构管理员去执行，比如硬件替换、升级、保养等。当然，和物业管理费这种机制一样，VMware的CMP平台也有相应的计费功能，会“明码标价”地提供云成本报表，提供租户和管理员参考，作为“IT创造价值”的一种直观度量。

注意：在vRA7.6的世界，计费是交给vRBu实现的；在vRA8.0以后的世界里，vROps承担计费的工作。

那相对应地，“租户”就好像是小区的居民，居民在自己家如何摆放家具，幸福快乐地生活是不会受到物业干涉的。

“蓝图”就好像是面向这个租户的一份完整的装修手册，满足租户的需求（我想要干湿分离的卫生间），有限度地并充分利用基础架构管理员提供的资源（装修不能改变房屋结构和违章建筑），提供服务（如何置备材料、打孔装修、交付验收）。

因此，确切地来说，蓝图蕴含着以下几个约定：

1.蓝图一定是满足租户业务要求的，无法满足业务要求的蓝图设计不会被用户采纳，用户不会去申请无法满足自己生产需要的服务；

2.蓝图一定是合规企业管理员制定的各项规定的，在基础架构管理员授权的有限资源下，提供租户服务；

3.蓝图定义了租户服务全生命周期的方方面面，包括了资源调度与置备以及其他个性化的定制。

在理解了“基础架构管理员”“租户”和“蓝图”这些最基本的概念之后，我们一起来看看如何勾勒出一个复合蓝图。

0x02.预留基础架构，提供蓝图架构师充分的发挥空间

俗话说“巧妇难为无米之炊”，在开始蓝图设计之前，管理员需要通过“端点”来集成包括vCenter Server（后文简称VC）提供的计算资源、NSX DataCenter Manager（后文简称NSX）提供的网络与安全资源等基础架构以及vRealize Orchestrator（后文简称vRO）来进行编排；最后通过“计算资源”同步和“架构组”划分来为“预留”提供充分的可选资源。

注意：vRealize Operations不能叫vRO，准确来说，它叫做vROps~

如上图所示，vRA可以调度包括VC、NSX等在内的多个组件，从而实现对群集、虚拟机、模板、软件定义网络、安全微分段这些对象集中统一的纳管和编排。

如下图所示，管理员为某些业务用户提供不超过64GB的内存预留、1TB的存储空间预留；那么，架构师在进行蓝图设计时，如果设计置备的虚拟机内存总数超过64GB，就像是“装修队搭建了违章建筑”是一种不合规的情况；实际上最终的用户们也无法申请总数超过64GB的内存。从某种意义上说，这里的“预留”更像是一种“约束”或者说“限制”。

而对于网络来说，预留同样代表这一种约束（如上图所示）；在“自动化的NSX网络交付”这篇分享中，我解释过NSX能够提供的按需交付网络和网络服务，这里我就不再赘述了；有了计算、存储和网络之后，接下来，就是蓝图架构师大展宏图的阶段了。

0x03.复合蓝图的设计

一个典型的符合蓝图大概会包括以下几个对象：

计算机/网络与安全/软件组件

我们不妨一个一个来看，首先是“计算机”。对于vSphere的环境来说，计算机实际上就是用户在申请服务后，由蓝图创建的若干台虚拟机。一个蓝图中可以有多个虚拟机实例，这些虚拟机可以被用做相同的功能，如上图中的WEB-TIER虚拟机，就是用来响应客户端的HTTP请求的；也可以是不同功能，如上图中的APP-TIER虚拟机和DB-TIER虚拟机。从逻辑上来说，一个蓝图中的虚拟机实例应当包含一定的关联性，比如WEB-TIER虚拟机接受用户的请求之后，会提交给APP-TIER虚拟机，APP-TIER虚拟机将会查询DB-TIER虚拟机中的数据库信息，并返回给WEB-TIER虚拟机，最终反馈给用户。

上文讲过，蓝图也定义了“资源置备”的方方面面，比如下图所示：蓝图定义了WEB-TIER虚拟机在以“克隆”形式被置备的时候，调用了哪个“模板”，附加了哪个“自定义规范”。

而这些模板也好、自定义规范也好，是通过“端点”VC在同步信息后，被vRA所纳管的。

除此以外，蓝图也会定义虚拟机能够被分配到的资源区间和其他置备虚拟机所需要用到的一些信息，比如网络。

“计算机”可以使用管理员在VC上预配置的分布式交换机（后文称vDS）的分布式虚拟机端口组（后文称DvPG），也可以根据实际的需要，由NSX自动创建出若干个分段，充分发挥软件定义网络的特性，来为自己业务的快速上线提供强大的助力。

如下图所示，三类虚拟机在被创建的时候，并不会使用VC上现有的DvPG，而是会根据实际情况，分别从WEB业务网络资源池、APP业务网络资源池和DB业务网络资源池中，自动被分配若干个可用的地址，实现L3互通。

这些网络配置文件是由基础架构管理员中的“网络管理员”角色去定义的，比如VC的DvPG将以“外部网络配置文件”的形式被定义，而NSX按需生成的逻辑网络将以“路由网络配置文件”的形式被定义；这些网络配置文件都会“以预留”的方式提供给蓝图使用。

因此，vRA本身就是一个IP地址管理器（后文称IPAM），无论虚拟机被连接到DvPG还是分段，IP地址的规划、分配、销毁、回收均可以由vRA来实现。

注意：对于一些特殊的情况，这个功能可以由vRO来实现，只是没有了vRA的IPAM，容易造成虚拟机的IP地址冲突，不利于管理员的维护，存在比较大的风险。

回到蓝图，心细的朋友一定会留意：在vSphere虚拟机的图标内，还能看到个蓝色的“软件组件”的图标。其实，这是vRA的精髓功能之一-软件组件，也是企业版才支持的功能。

设身处地，站在用户的角度来看，当我申请并拿到一台MYSQL数据库虚拟机的时候，理所应当地，这台虚拟机已经完成一系列MYSQL数据库的配置，包括：

ROOT管理员密码、自定义凭据的管理员、若干个预先创建的数据库，而自定义的管理员默认就应该是这个数据库的管理员等等。

这些需求非常的合理，却难以在虚拟机或者模板这个层面去实现。有人会说，管理员可以在VC上创建一个预先装好MYSQL的模板。若真如此，VC上的模板数量会非常多，反而造成系统管理员沉重的运维负担。

那软件组件是如何来实现用户的这类需求呢？我们来看看软件组件的细节吧。

如上图所示，管理员定义了若干个参数，如mysql_bind_address、mysql_user_name；这些参数可以是由用户手动输入（可以有一个默认值），如mysql_user_name；也可以“不在请求中显示”，以隐性方式存在，如my_bind_address。

我们可以看到，mysql_bind_address的数值是“_resource~S7-SE3-Tier-DB~ip_address”，意味着当DB-TIER虚拟机被成功置备后，系统会自动获取到这个虚拟机的IP地址，然后传递给这个参数。

现在，我们就可以回答一个问题“APP-TIER虚拟机如何知道DB-TIER虚拟机的IP地址，然后向它发起MYSQL查询的呢？”

答案就是，vRA将DB-TIER的IP地址、数据库信息、管理员凭据等传递给了APP-TIER虚拟机。

这些参数将根据软件组件的定义，完成一系列自动化的配置，如下图所示：

说到这里，我们还需要解决3个问题：

虚拟机置备的时候如何来定义优先级顺序，确保在安装APP-TIER虚拟机的软件组件的时候，系统可以正确获取DB-TIER的IP地址，然后传递给APP-TIER的软件组件？

虚拟机实例本身的一些参数，比如虚拟机名，如何实现用户的自定义呢？

用户希望在虚拟机被创建后，在企业内部全局DNS服务器上添加对应的正反向解析记录，此类需求如何来实现？

我们先来回答第一个问题。通过对上图的观察，可以看到软件组件之间，有虚线箭头，如APP-TIER虚拟机上方的软件组件，指向下方和右侧DB-TIER的软件组件，同时也有WEB-TIER虚拟机的一个软件组件将箭头指向了它。

其实箭头方向代表着优先级顺序，比如：

这就表示了，只有当“S7-SE-3Tier-DB”这个软件组件被成功执行了以后，才会执行“S7-SE-3Tier-App”这个软件组件，这样可以确保用户定义的MYSQL的一系列参数会成功传递给APP-TIER的软件组件。

如下图所示：我们在蓝图置备的结果工作流中，可以非常清晰地看到这点。

再来看第二个问题，对于需要自定义的各种情况，vRA有很多实现的方式，包括属性词典、自定义属性、组件配置文件等等。比如管理员定义了一个如下图所示的属性后，当用户申请服务的时候，就可以根据自己的实际情况进行填写；蓝图的工作流将会这些信息传递给真正使用到它的组件，它可以是软件组件、也可以是系统自带的工作流、或者是自定义的工作流。

最后来看看第三个问题。其实，对于Windows操作系统来说，系统管理员可以通过VC的自定义规范，将置备的虚拟机直接加入到AD域中成为成员服务器。这样的话，系统自动会在DNS服务器角色上添加这些记录。但如果是Linux操作系统的场景，那么就需要额外的工作流来实现，并且通过“订阅”的方式来触发。

如上图所示，通过一个简单的订阅，蓝图在执行虚拟机的置备之后，会通过vRO执行一个添加DNS记录的工作流。

当然，想要实现这个需求，需要架构师访问vRO，完成对应的工作流编写，包括定义一些变量、传递一些参数、执行一些脚本等等。

上述这些步骤，并非所有的蓝图都会用到。但为了实现用户的需求，都是一些非常有用的知识点，希望各位能通过今天的分享充分了解到。

其实复合蓝图不仅仅包括这些，还有一些其他的东西，比如“按需负载均衡器”~

又比如是XaaS类型的蓝图~

不过，在用户真正调用这些蓝图之前，还需要一些其他的操作~就好像“装修指南”要最终落地，需要经过租户的选择、申请、物业的审批等等，这就是vRA的审批策略、业务组、服务这些概念的实际功能。

最后，因为杭州的这个项目包含了VMware SDDC全系列产品，我想在这里说说晓冬接触VMware SDDC这不到两年以来的感想吧：

其实软件定义数据中心这个概念，早在8年前就已经被提出来了，它代表着企业应用承载的一种趋势。就拿虚拟化这个老掉牙的概念来说，早就不是几台虚拟机那么回事了。但即便在这种浪潮下，真正运行完整版SDDC（软件定义计算、软甲定义存储、软件定义网络和云管理平台）的企业毕竟还是少数，这里面有成本的考量、有架构的约束、有很多类似的非技术因素。但最重要的，是基础架构或者云平台，是为应用、为业务而存在的。过多关注基础架构的实现或者实施花哨的平台，其实对企业业务稳定运行本身来说，是毫无用处的。能够在充分满足业务需求的前提下，同时提供M高可管理性、A高可用性、P高性能、R高可恢复性、S高安全性和C合规性的解决方案，才是适合客户选择的最佳方式。

只是与客户不同的是，作为一名技术人员，我需要去关注技术的每一次革新。成熟的商用产品是精妙的剑招，丰富的经验是制胜的剑意，两者相辅相成，才是成熟的解决方案，称得上武林高手。

接下来，因为有粉丝“点菜”，我会聊聊NSX与虚拟桌面的紧密结合。在VCF4.0正式发布后，我会在Homelab搭建VCF4.0，届时再与诸位分享“面向应用的”VMware Cloud Foundation，敬请期待。