VRO基础入门（七） - Plan Step · 上篇

2023-06-14 | 阅读：次

系列目录：

VRO基础入门（一）- 简介
VRO基础入门（二）- 安装与部署
VRO基础入门（三）- 基本组件 · 上篇
[VRO基础入门（四）- 基本组件 · 下篇]
[VRO基础入门（五）- 成功灾备计划的第一步]
[VRO基础入门（六）- 数据实验室]
[VRO基础入门（七）- Plan Step · 上篇]
[VRO基础入门（八）- Plan Step · 下篇]
[VRO基础入门（九）- 文档模板解析]
[VRO基础入门（十）- 使用VRO搭配K10实现全自动容器灾备]

在之前的帖子中，我们详细讨论了Orchestration Plan的创建过程。在每个Orchestration Plan中除了基础的这些创建步骤之外，这个系统重最重要的是它的自动化流程，这个自动化流程是通过Powershell脚本来实现。在VRO中，这些Powershell的自动化脚本被封装在Plan Step中，由VRO的Orchestration Plan来调度执行和传递参数。

每个Orchestration Plan创建时，会带入默认的几个Plan Steps，这几个基本上就是我们每次灾备都会涉及的开机关机等操作。管理员可以编辑Orchestration Plan，在其中加入一些额外的Steps。

Orchestration Plan的详细管理和使用方法

在VRO的主界面中，找到左边的Orchestration Plans，点击它后进入Orchestration Plans仪表盘，选择一条我们要编辑的Plan，点击Plan名字，即可进入该Plan内。

在Plan Details中，可以看到从左到右的5个按钮分别是Run、Halt、Check、Undo和Edit，其中包含了三大经典按键：Run是执行键，Halt是暂停键，Undo是取消键。除了这3个之外，Check是Plan检查就绪状态的按键，如果就绪状态failed，那么这个计划在执行时很大可能就会失败；Edit是今天要详细介绍的，我们用来加入自动化流程的主要按键。点击Edit之后，能进入Plan的编辑界面。

在Plan Edit界面中，整个布局呈从左到右的顺序排列，在最左边的框中是计划的分组，点击左边的框中的内容后往右依次会展示这个对象下的包含的对象和可用操作。

在最左边的框中有Pre-Plan Steps和Post-Plan Steps这两个默认的分组和用户定义分组，其中位于两个默认组中间的用户定义分组是有比较多的调整内容的部分，可以通过Add或Properties打开设置向导，进行一些配置，这些配置和之前提到的创建Orchestration Plan中的部分内容基本相同，换句话说就是在创建完Plan后，还需要调整创建过程中的部分参数，可以来这里调整。

而对于Pre-Plan steps和Post Plan steps这两个Group来说，这两个Step并不包含任何的实际机器，因此使用者无法调整这两个Plan的任何属性。然而VRO能够让我们往这两个Plan Steps的Group中添加一些steps，这就能够让我们能够在VRO的正式执行Plan之前或者之后执行一些自定义流程了。点击Pre-Plan Step后，右边的框会出现具体Steps的选项，默认情况下，里面没有任何记录，可以通过Add按钮来添加，如下图。

在这里可以添加的VRO系统内置的Step有：

Generate Event - 生成一个Windows事件，记录在Windows event viewer中。
Send Email - 发送电子邮件。
Veeam Job Actions - 操作VBR上的备份或者复制作业，可以进行Enable、Disable、Start、Stop这4个操作。
VM Power Actions - 操作VC上的虚拟机开关机，这对于灾备中心切换前关闭不重要的机器释放资源用于切换会非常有用。
其他任何用户定义的Powershell脚本。

对于用户定义分组，里面包含的是实际要做restore或者failover的机器，这时候，当我选择某个机器时，VRO就会让我定义这台机器执行restore或者failover时我需要加入的Step，对于已经添加的Step，也可以修改执行先后顺序和定义详细参数。

在这里出厂内置的Step有以下这些，我做了个简单的分类：

应用验证类：12个（AD、Exchange、Sharepoint、SQL和IIS）
虚拟机验证类：2个（心跳和ping包）
事件通知类：2个（Windows Event和邮件）
资源操作类：3个（虚拟机开关机、Windows服务启动、源虚拟机关机）

Plan Step通用参数

在每个Plan Step中，都会包含一个最基础的Common Parameter，这是对于这个Plan Step执行的基本控制条件，包含以下内容：

During Failback & Undo : 决定在Failback和Undo Failover操作时是否执行脚本
During Lab Test : 决定在Datalab测试中是否使用脚本
Critical step : 定义这个Step对于整个Plan是否重要，如果是，则失败后立刻停止计划
Timeout : 定义整个Step执行超时时间
Retries : 定义失败重试次数

这些参数可以在每个Orchestration Plan中为每个step单独调整。

自定义脚本

VRO还提供了自定义脚本功能，管理员可以在VBR服务器或者恢复后的系统上直接调用使用Powershell脚本，完成各种骚操作。

举个例子，数据中心某应用架构如下：

典型的三层架构，Oracle数据库在AIX小机上，中间件和应用服务器跑在VMware vSphere上面。灾备系统设计之初，Oracle数据库通过OGG做了复制，实现了数据级同步。

这样的架构，通常Veeam使用VBR的时候会建议用户对虚拟化平台也做一个保护，确保在主数据中心出现故障的时候能够应用系统和数据库都切换至灾备中心。而在使用了Veeam的解决方案后，通常我们的用户都会发现，VBR不仅能够很好的完成虚拟化平台的灾备复制任务，同时他的灾备演练能力也极其强大，系统会真实的被恢复出来并且提供恢复后的演练访问，真枪实弹的完成整个演习过程，并且还是全自动的。

但是，管理员很快会发现，很尴尬的一点是，应用系统没有数据库的数据支持，就算恢复了，也没办法正常工作，这样的测试还是无法最终等效于实际灾备场景。

VRO来帮忙

这事情借助VRO，可以完美的解决。整个过程会是这样：

启动应用系统的Failover / Restore Plan，可以在真正的恢复过程前的Step中，加入Powershell脚本，和灾备站点的AIX进行通讯。
AIX上脚本执行后，新的LPAR部署出来。
再来一个脚本，将一个虚拟网卡attach到新部署出来的LPAR上，并让这个网卡和我们在虚拟化环境中创建出来的沙盒隔离网络相连，隔离网络无法直接路由访问到生产，所以是相对隔离的环境。
第三个脚本搞起，让最新的一份Oracle数据库运行在这个新的LPAR上。
一切准备结束，启动虚拟化灾备平台中的应用和中间件副本，这样在这个隔离环境中，起来的应用和中间件就可以访问AIX数据库了。
到这里还没完工，系统都跑起来了，让这套系统别停下，飞一会儿吧，可以在上面做一系列测试、开发等等操作。
经过一段漫长的测试，系统使用完毕，灾备管理员被通知可以回收了。灾备管理员操作VRO，让系统进入下一步流程。
vSphere上的虚拟机被Undo Failover到演练之前的状态，这个非常简单，和VBR上几乎没差别。
一个新的脚本被触发，通知AIX，请删除这个LPAR和他上面的数据库，确保测试的数据不会被复制回生产中。

以上这个过程，是不是很不错？这样的过程不仅可以是加入和AIX的配合，同样各种系统不管是HPUX还是Oracle Exadata都可以搞一搞。对了，还有公有云，一起加入到这个灾备Party中吧，有了VRO，这都不是事。

所以，有了自定义脚本和计划任务的调度，VRO神通广大，几乎能做任何由Powershell可以实现的事情。在下一篇，我会来详细介绍如何玩转这个自定义脚本。