一份可用的vRA8演示用例-阿里云开发者社区

0x01.准备工作

既然是一个“能拿得出手”的演示用例，自然需要提前做好充分的准备。首先说明一下笔者的Lab环境。U1S1，这个演示用例对硬件服务器是有一定的容量和性能要求的。拥有充足的容量，可以确保基础架构服务器和交付的应用虚拟机可以健康稳定地运行。网络适配器和数据存储的性能也直接影响部署效率，尤其是数据存储，建议各位采用VMware vSAN（后文称vSAN）或者FC SAN，尽量避免采用本地存储或者千兆网络挂载NFS存储的方式。

基础架构组件的部署就不多细讲了，至少需要将环境就绪到如下基线：
1. vSphere就绪，包括网络、数据存储、群集、NTP、DNS等，可以通过VC管理整个群集。
2. NSX就绪，包括将VC添加成为计算管理器，创建OVERLAY和VLAN传输区域，并完成对应群集的NSX配置工作。

3. vRA组件就绪，通过Lifecycle Manager（后文称VLCM）的ISO安装镜像，依次完成VLCM、Identity Manager（后文称VIDM）以及vRA的部署工作，确保可以使用定义的vradmin管理员账户访问vRA门户网站即可。

0x02.VC需要做的事

接下来说说VC层面需要进行的配置工作。其实与其说是VC的配置，不如讲是虚拟机模板的制作。与其他普通的虚拟机相同，管理员需要执行如下操作：

▪VMware Tools安装；
▪Cloud-Init和Cloud-Utils安装。

当然，笔者是直接下载并执行大拿提供的脚本，从而免去了不少翻看官方笔记的时间。详情可以参考大拿的博客：http://www.vmlab.org/642.html最后千万不要忘记将虚拟机转换成模板，并且为他定义一个合规的名称，以便于vRA8同步。

0x03.NSX需要做的事

如果说之前有过使用NSX(无论是NSX-V还是NSX-T)和诸如OpenShift、Openstack或者vRA早些版本集成的经历，那么对于NSX“需要做的事”应该说是“一目了然”的。我们知道，在vSphere with Tanzu的架构中，管理员为了能顺利通过vCenter部署主管群集，是需要在NSX-T上完成一系列配置操作的，其中最重要的两项是：

1》完成NSX基础设施的配置工作，如ESXi主机传输节点NSX配置、Edge边界传输节点及群集的部署；
2》完成Tier0网关的配置工作，如Uplink上联配置、动态/静态路由协议的配置。其实在之前笔者分享的NSX-T与OpenShift、Openstack集成配置中，也都包括了“完成Tier0网关的配置工作”这个关键步骤。这也很容易理解，因为在NSX-T的架构中，Tier0网关类似于运营商级或者IT管理级的设备。对于NSX-T与各类产品集成的场景中，Tier1网关才是真正承载业务南北向和东西向交互的组件，可以理解为租户级的设备。无论是OpenShift创建出来的命名空间、Openstack创建出来的逻辑交换机还是vRA创建出来的租户网络，最终都会以NSX分段的形式连接到自动创建的Tier1网关上。

一个Tier1网关可以看成是一个业务的边界，Tier1网关之间的网络默认是不可互访的，就好像各个租户、各个不同的业务之间，原则上不应该存在互访的流量(除非管理员开通防火墙策略)。同时，为了满足业务和外部网络(包括互联网)的通信，这些Tier1网关就可以通过连接到Tier0网关来实现这个需求。

当然，如果管理员不采用vRA8的按需网络，而是采用现有的NSX-T分段或者分布式交换机，那可能就是另外的一张拓扑了。只不过，既然是一个vRA8 with NSX的实例，自然应该最大化云管理平台的效率，建议采用NSX-T按需网络的方式来呈现。回到演示用例本身，我们来看看笔者在NSX上的配置。

▪ESXi主机传输节点的配置，最关键的一点：需要被Overlay传输区域覆盖

▪Tier0网关的配置：包括上行链路、路由协议和重分发策略以及HA冗余

▪至于上行链路是2根还是4根，这个取决于演示环境自身。

▪需要注意的是，对于采用BGP/OSPF此类动态路由协议的场景来说，为了实现vRA创建的按需网络与外部网络的连通性，一定不要忘记在路由重分发页面，至少将“Tier-1子网下的已连接接口和分段”进行勾选。

0x04.vRA需要做的事

无论是vCenter还是NSX，说到底是基础架构层的配置工作。接下来，我们进入正题，来看看vRA上需要的配置。为了便于各位参考，我把YAML配置文件共享出来，提供下载：

https://github.com/Antares-Docker/vra-yaml/blob/main/CentOS77-MySQL-MasterSlaveMode.yaml

顾名思义，笔者的测试用例最终会部署两台CentOS7.7版本的虚拟机，两台虚拟机将部署MySQL组件，并自动组成Master-Slave群集实现冗余。

在YAML文件里，可以看到笔者定义了以下变量：

image：镜像，对应vCenter服务器上的虚拟机模板；

flavor：“风味”，可以理解为部署虚拟机对应的规模大小，类似通过OVA部署虚拟机时，管理员需要定义其规模，包括“小型”“中等”“大型”等；

osusername等一系列变量：对应MySQL主从数据库所需要用到的一系列对象，包括操作系统名称和密码、数据库用户名和密码、数据库root账户密码、数据库名。

除了变量之外，还定义了三个对象：

MysqlMasterNode：主从数据库中的Master节点，以及通过Cloud-Init执行的一系列Shell命令；

MysqlSlaveNode：主从数据库中的Slave节点，以及通过Cloud-Init执行的一系列Shell命令；

Mysql-Node-Network：两台CentOS虚拟机上联的NSX-T分段，属于按需分配的网络，由vRA驱动NSX-T自动创建和管理。

为了便于理解，笔者描绘了一张拓扑，来标识出变量和对象之间的某种关系。

其实vRA的配置过程，就是声明并且限定变量和对象的过程。我们不妨逐一来看看为了实现演示用例，vRA进行的一系列定义操作。

0x0401.Project定义

其实每一个通过YAML文件置备出来的部署(vRA中称这种叫做Deployment)、包含YAML配置文件本身的蓝图、以及可以访问并使用蓝图的用户和角色等等，都可以归类为某一个项目Project。

VMware官方对于Project的定义非常直观：

项目规定了谁有权访问该蓝图以及该蓝图的部署位置。

可以使用项目来组织和管理用户可以做什么，以及他们可以在您的云基础架构中将蓝图部署到哪些云区域。

在具体的项目中，可以根据项目来划分不同的网络区域或者是功能区域。

因此，管理员在vRA上的第一个配置就是定义项目Project。

路径：【Cloud Assembly-Infrastructure-Administration-Projects】

在这个阶段，暂时只需要定义Project的名称以及成员即可。

各位可以根据实际需要，定义项目成员。笔者此处只定义默认账户vradmin单个用户。

0x0402.Cloud Accounts定义

对于从蓝图中创建的部署来说，“总需要有一个地方来运行虚拟机”。因此对于vRA而言，需要定义和vCenter、NSX-T以及其他包括AWS等资源在内交互的账号，才能同步包括模板、虚拟网络等在内的诸多信息。

因此，接下来要做的事情，就是定义各类云账号。

路径：【Cloud Assembly-Infrastructure-Connections-Cloud Accounts】

管理员需要将所有vRA纳管的对象，如多台vCenter、多个NSX-T都进行正确的配置。

当管理员完成与vCenter、NSX-T对象的关联之后，vRA会定期同步诸如虚拟机模板之类的信息。如果管理员在vCenter上新建了某个模板，但是在vRA上无法同步到的时候，就需要手动来此处点击“SYNC IMAGES”进行刷新。

正确同步的标识，是管理员可以在Resources标签页下，读取到诸如群集之类的计算资源和NSX-T现有的分段或者分布式交换机上的虚拟机端口组等信息。

0x0403.Cloud Zone定义

云区域定义了一组可用于蓝图置备的计算资源；每个云区域都会与一个具体的项目关联，蓝图部署在相应的云区域计算资源范围中。

管理员需要通过Cloud Zone完成蓝图与项目之间的关联。

路径：【Cloud Assembly-Infrastructure-Config-Cloud Zones】

在这个界面，有几个值得留意的地方：

Folder：将来置备的虚拟机，都会被放置到对应vCenter的该文件夹下Capability tags：对于YAML文件来说，虚拟机放置到哪个Cloud Zone是通过Tags标签来约束Constraint的。这个参数尤其重要！

在YAML文件中，笔者定义的MysqlMasterNode最终将部署在标签为“Project-Nellie-Test”的云区域上。对于需要更为精细化的场景，管理员可以针对群集、数据存储等进行标签定义，并且在YAML文件中进行调用。

还记得在之前的步骤中，我们所定义的项目Project么？

现在可以在刚才的项目Provisioning页面，将新建的云区域进行关联。

当然，在这个页面还有一些其他有用的参数可以进行定义。比如定义置备虚拟机的命名。如下图所示，该项目置备的虚拟机将以MySQLNodeT+三位数字的格式进行命名。对于一些存储性能并不是特别好的演示或者测试环境，建议将请求超时时间调大，避免“过早超时”导致置备失败。

0x0404.Image定义

路径：【Cloud Assembly-Infrastructure-Config-Image Mappings】

管理员需要点击【+NEW IMAGE MAPPING】来同步并且定义YAML配置文件所能调用的虚拟机模板。

还记得之前提到的“千万不要忘记将虚拟机转换成模板，并且为他定义一个合规的名称，以便于vRA8同步。”么？这里就需要读取并同步vCenter上的模板。

注意，虽然在vCenter上，这个CentOS操作系统模板名称为centos77，但是如下图所示，笔者在vRA8上定义的是img-centos77这个映象，因此在YAML文件中声明并且调用的，也必须是image-centos77这个命名。

如果各位想要提供CentOS7.6、CentOS7.7、CentOS7.8多种镜像，那么只需要在vCenter上创建并转换多个模板，然后在vRA上定义多个Image映像即可。

通常情况下，为了提升用户体验，管理员可以定义一个默认值。如上图所示，默认的Image映像为img-centos77。

0x0405.Flavor定义

路径：【Cloud Assembly-Infrastructure-Config-Flavor Mappings】

管理员需要点击【+NEW IMAGE MAPPING】来同步并且定义YAML配置文件所能调用的虚拟机模板。

通常情况下，Flavor的定义可以在多个可用区一致。这里给出笔者演示用例的定义，提供各位参考：

当然，管理员也可以根据实际情况定义在不同的可用区采用不同的硬件分配。

在YAML文件中，通过调用Flavor变量提供申请用户对虚拟机硬件分配大小的选择，这一点和Image变量相同。

0x0406.Network Profile定义路径：【Cloud Assembly-Infrastructure-Config-Network Profiles】

笔者的演示用例是采用“NSX-T按需网络”作为网络模型来实现的。简单说明一下什么是“按需网络”。如果在置备虚拟机之前，管理员已经创建了分布式交换机的虚拟机端口组或者NSX-T的分段，虚拟网络的创建并非由vRA驱动，虚拟机在被vRA创建后会连接到“已经存在的”网络，这种网络模型叫“现有网络”。对于采用现有网络的场景来说，优势在于网络置备和管理的方式简单，避免复杂的工作流；vRA可以通过网络配置文件对IP地址的分配进行管理，避免人为因素导致网络IP冲突情况的发生。但缺点在于管理员需要预先创建虚拟网络，相对于软件定义数据中心而言，略显笨重、缺乏灵活性、无法最大化云管理平台的自动化效益。“按需网络”是管理员提前定义一个充足的网络资源池(比如20位子网掩码的地址段)，当一个应用(若干台虚拟机)被置备的时候，vRA会驱动NSX-T创建有合适IP地址容量的分段和网关，取代原先管理员手动配置的过程，然后再将虚拟机连接到创建的分段上。相对于现有网络，虽然按需网络多了NSX网络自动置备的工作流，但是它本身是由vRA驱动执行，不会出现人为的错误和遗漏，同时避免了IP地址段生硬的人为划分，避免出现不同资源池IP地址使用不平衡的问题，是最大化云管理平台自动化效益的一种方式。

回到配置本身，来看看匹配笔者演示用例的按需网络配置文件是如何设置的。

▪定义一个被YAML文件后续调用的标签

相对应地，在YAML文件中，可以通过constraints来确保虚拟机创建的时候，vRA会根据这个按需网络配置文件自动创建网络，并且将虚拟机连接到这个NSX-T的分段上。需要注意的是，在YAML文件上定义这个网络的类型必须是“routed”。

▪在“Networks”页面，需要添加一个现有的网络。这个网络需要提前在NSX-T上创建分段，但是并不需要将它连接到任何Tier0或者Tier1网关。

这个配置最大的作用是提供了可用的DNS服务器和DNS搜索空间的定义。

▪在网络配置文件的“Network Policies”网络策略页面，管理员需要定义两大块参数：Isolation policy：选择on-demand network，即按需网络；transport zone：在vRA配置与NSX-T集成的账号后，可以自动同步到对应的NSX-T的传输区域，这里必须要选择Overlay类型的传输区域；External network：这里选择刚才创建的网络，主要是为了提供DNS服务器和DNS搜索空间这两个关键参数。（这里也是笔者配置时候的一个疑问，这个外部网络不会被后续置备的虚拟机所使用到，但是却是必须要配置的一个参数，有点类似于原先vRA与NSX-V集成时使用的trasnsit network，也不确定笔者这样的理解是否真的正确）Tier-0 logical router：选择Tier0网关，所有vRA调用这个网络配置文件创建生成的NSX-T分段都会连接到一台Tier1网关，这个Tier1网关同样是vRA自动创建的，并且会被连接到这个定义的Tier0网关上，实现与外部网络的互联互通。
Edge cluster：对于Tier1网关来说，如果蓝图会创建负载均衡器这样有状态的服务，那么会在这个定义的Edge群集上创建对应的Tier1网关的服务路由器角色。

上述参数，更多的是架构层面的定义和配置。vRA在NSX-T上创建分段的网络参数则是由下面的配置定义的：

这些参数需要联合起来“阅读理解”。当用户申请一个服务之后，如果这个服务对应的蓝图(YAML文件)最终会调用这个网络配置文件，那么vRA会驱动NSX-T创建出一个28位掩码，并且属于172.20.26.0/24这个大地址段的网络，所有的可用IP地址的管理、维护和分配，全部由vRA自己来驱动(Internal)，分配的方式是固定IP的形式(Static)。

如下图所示，当有用户申请了某个服务。NSX-T会被vRA驱动创建一个分段。172.20.26.0/24可以提供一共16个可用的28位掩码的分段。在vRA确认IP地址范围可用的情况下，创建了一个172.20.26.0/28的分段，且第一个可用的IP地址被分配作为网关来使用。

而创建的Tier1网关也会自动连接到预先配置的Tier0网关上。

vRA置备的虚拟机，也会自动分配可用的IP地址。

0x0407.Blueprint蓝图设计路径：【Cloud Assembly-Design-Cloud Templates】管理员根据需要还可以定义数据存储配置文件。在笔者的演示用例中，因为群集启用了vSAN数据存储，也没有其他的外置存储。在定义可用区的时候，直接设置虚拟机会置备在vSAN上了。
接下来，就是完成最后的蓝图设计工作。很多人会觉得做一个演示用例很复杂，很大程度的原因就是不知道YAML文件怎么写。这里给出笔者的一些经验，提供各位参考。

▪第一步，用拖拽的方式完成基本框架。
在Cloud Template云模板界面，管理员可以选择新建一个空白的蓝图。

如下图所示，在添加了虚拟机*2以及NSX-T网络*1之后，蓝图的基本框架就完成了。

▪第二步，完善变量和属性。

在之前vRA7的年代，通过蓝图+软件组件=复合蓝图的方式，vRA可以在交付的虚拟机操作系统上执行一系列个性化的配置以及安装各类软件。vRA8可以通过Cloud Init来实现相同的功能，这里面就需要管理员在YAML文件上做两大类的配置：其一就是如下图所示的各类Input输入。

当用户申请服务的时候，这些Input中的就会需要用户输入或者选择。

其二，就是操作系统层面执行的各种命令。
比如创建用户定义的账户并且定义密码、安装软件(如本用例中的MySQL数据库)、执行MySQL的初始化等等......

有时还需要在虚拟机之间相互传递变量，比如笔者的用例是创建一个MySQL的主从数据库，那对于从数据库来说，就必须要知道主数据库的IP地址。这个IP地址并未是预先可知的，而是需要在vRA的网络配置文件自动分配给主数据库一个可用的IP地址后，才能传递给从数据库知晓的。因此，在runcmd下还会存在变量的传递。

如上图所示，通过命令笔者将MasterNode主节点的IP地址传递给了SlaveNode从节点(赋值给Mhost这个变量)。

这里给个小建议：为了验证代码执行是否成功并且正确，可以适当地考虑打印出一些变量。比如笔者一开始并不确定通过这种方式一定将主数据库的IP地址传递给了Mhost变量，因此会选择将它打印出来。届时只需要访问从数据库的虚拟机，查看/tmp/mysql.masternodeip.txt中的IP地址是否匹配主数据库的IP地址就行了。在共享给各位的YAML文件中，有很多这样被#注释掉的命令，都是为了验证命令是否执行正确特地保留的。第三步，就是跑一下验证一下YAML是否真的可用了（演示用例能不能展示了）。