在此场景中,主站点 1 由于计划的维护作业或未计划的电源故障而关闭。所有工作负载在辅助站点 2(升级的主站点)上运行,并且流量通过站点 2 上的 UDLR 和 NSX Edge 进行路由。现在,原来的主站点 1 已重新启动,NSX 管理员希望在原来的主站点 1 中恢复 NSX 组件并还原所有工作负载。
NSX 管理员希望实现以下主要目标:
- 以最短的停机时间完成所有工作负载从站点 2 到原始主站点 1 的整个故障恢复。
- 通过故障恢复到站点 1 后,保留应用程序 IP 地址。
- 在站点 1 上自动恢复所有 Edge 接口设置和 BGP 协议配置设置。
注:
- 管理员可以通过使用 vSphere Web Client 或运行 NSX REST API 来手动执行故障恢复任务。此外,管理员也可以通过在故障恢复期间运行包含所需运行的 API 的脚本文件来自动执行某些故障恢复任务。此场景介绍了使用 vSphere Web Client 的手动故障恢复步骤。但是,在执行任何步骤时,如果需要使用 CLI 或 NSX REST API,场景中也提供了充分的说明。
- 在此场景中,灾难恢复工作流特定于前面所述的拓扑,其中具有一个主 NSX Manager 和一个辅助 NSX Manager。此场景不涉及具有多个辅助 NSX Manager 的工作流。
前提条件
- 在站点 1 和站点 2 上安装 NSX Data Center 6.4.5 或更高版本。
- 在站点 1 和站点 2 上使用增强型链接模式部署 vCenter Server。
- 站点 1 和站点 2 满足以下条件:
- 非 NSX 防火墙(如果有)上未配置任何应用程序特定的安全策略。
- 非 NSX 防火墙(如果有)上未配置任何应用程序特定的防火墙规则。
- 在这两个 ESG 上禁用防火墙,因为会在 UDLR 上启用 ECMP,并且可以确保允许所有流量。
- 在站点 2(已升级为主站点)上,启动故障恢复流程前未在通用逻辑组件中进行任何更改。
过程
结果
手动将所有 NSX 组件和工作负载从辅助站点(站点 2)故障恢复到主站点(站点 1)的过程已完成。
下一步做什么
通过在站点 1 上执行以下步骤,确认故障恢复到主站点 1 的过程已 100% 完成:
- 检查 NSX Manager 是否具有主要角色。
- 检查是否在 UDLR 上部署了控制虚拟机(Edge 设备虚拟机)。
- 检查是否所有控制器群集节点的状态均为已连接。
- 对为 NSX 准备的每个主机群集执行通信运行状况检查。
- 导航到 。
- 选择站点 1 上的 NSX Manager。
- 一次选择一个群集,并检查群集的通信通道运行状况是否为“已启动”。
- 对于群集中的每个主机,检查主机的通信通道运行状况是否为“已启动”。
- 检查主机准备状态是否为绿色。
- 登录到 UDLR 控制虚拟机(Edge 设备虚拟机)的 CLI 控制台,然后执行以下步骤:
- 运行 show ip bgp neighbors 命令检查是否已建立所有 BGP 邻居,并且其状态为“已启动”。
- 运行 show ip route bgp 命令检查是否可从所有 BGP 邻居中发现所有 BGP 路由。
在故障恢复到站点 1 的过程完成后,所有工作负载在主站点 1 上运行,并且流量通过站点 1 中的 UDLR 和 NSX Edge 进行路由。