本篇将进行简单的GSLB测试用于验证之前的五个步骤部署GSLB正确无误。
在进行GSLB的演示测试之前，管理员需要确认GSLB服务是否运行正常，这里面涉及两层含义：
站点A的DNS服务活检本地GSLB虚拟服务正常即172.30.73.200活检172.30.73.211运行正常；
同时活检远端GSLB虚拟服务正常即172.30.73.200活检172.30.74.211运行正常；
反之，另一个活动成员站点的DNS服务172.30.74.200活检172.30.74.211以及172.30.73.211正常。
在笔者的环境中，在完成所有的GSLB配置后，查看GSLB服务活检状态如下图所示：
可见此时笔者跨站点的GSLB虚拟服务活检失败；原因是笔者尚未为承载DNS虚拟服务的服务引擎SE添加路由条目，以至于172.30.73.200无法ping通172.30.74.211、172.30.74.200无法ping通172.30.73.211；因此只需要为对应的服务引擎添加路由即可；
此后，可以看到GSLB服务已经双向活检正常；
接下来笔者使用一台Ubuntu客户端，将其DNS设置为企业DNS，然后尝试解析opencart.gslb.homelab.local，可以看到两次域名解析被轮训到不同的两个虚拟服务（172.30.73.211以及172.30.74.211）。
接下来，验证当一个站点出现故障的场景：
为了能够更好地呈现出效果，编辑Opencart网站config配置文件，将HTTP Server设置为服务器自身的真实IP地址，也就是10.10.1.111、10.10.1.112、10.10.1.211三个网络地址。
访问GSLB域名，即http://opencart.gslb.homelab.local
随后随便点一个链接，因为web.config的设置将会看到实际响应的后端服务器IP地址，如本示例中的10.10.1.112；
随后，在vCenter服务器上关闭web-11以及web-12两台服务器；
在AVI控制器管理平台上，可以看到SitePri站点的虚拟服务已经呈现“红色”不可用的状态；
再次访问http://opencart.gslb.homelab.local，可以看到依旧可以正常访问网站，实际上该网站是由SiteSec站点的虚拟服务对外提供业务的；
点击任意链接，可以看到后端的服务器真实IP是10.10.1.211，说明容灾切换成功。
