在此场景中，一场自然灾害侵袭了位于 Palo Alto 的主站点 1，导致站点 1 完全关闭。NSX 管理员将执行到位于 Austin 的辅助站点 2 的手动故障切换。

由于主站点是因无法预料的情况而关闭的，管理员不可能在实际故障发生之前执行任何故障切换的准备工作。

NSX 管理员希望实现以下主要目标：
  • 在站点 2 上以最短的停机时间实现整个站点的故障切换。
  • 故障切换后，在站点 2 上保留站点 1 应用程序 IP 地址。
  • 在站点 2 上自动恢复所有 Edge 接口设置和 BGP 协议配置设置。
注：
  • 管理员可以通过使用 vSphere Web Client 或运行 NSX REST API，手动执行故障切换任务。此外，管理员可以通过运行包含要在故障切换期间运行的 API 的脚本文件来自动执行某些故障切换任务。此场景介绍了使用 vSphere Web Client 的手动故障切换步骤。但是，在执行任何步骤时，如果需要使用 CLI 或 NSX REST API，场景中也提供了充分的说明。
  • 在此场景中，灾难恢复工作流特定于前面所述的拓扑，其中具有一个主 NSX Manager 和一个辅助 NSX Manager。此场景不涉及具有多个辅助 NSX Manager 的工作流。
重要说明： 如果在故障切换到辅助站点 2 的过程中打开主站点 1 的电源，请先使用此场景中的过程确保故障切换过程已完成。只有在彻底完成到辅助站点 2 的故障切换后，才能将所有工作负载还原或故障恢复到原始的主站点 1。有关故障恢复过程的详细说明，请参见 场景 3：完全故障恢复到主站点。

前提条件

  • 在站点 1 和站点 2 上安装 NSX Data Center 6.4.5 或更高版本。
  • 在站点 1 和站点 2 上使用增强型链接模式部署 vCenter Server。
  • 站点 1 和站点 2 满足以下条件：
    • 非 NSX 防火墙（如果有）上未配置任何应用程序特定的安全策略。
    • 非 NSX 防火墙（如果有）上未配置任何应用程序特定的防火墙规则。
    • 在这两个 ESG 上禁用防火墙，因为会在 UDLR 上启用 ECMP，并且可以确保允许所有流量。
  • 在故障切换之前，站点 2 满足以下条件：
    • 已在 ESG 上按照站点 1 上的配置手动配置了类似的下行链路接口。
    • 已在 ESG 上按照站点 1 上的配置手动完成了类似的 BGP 配置。
    • 当主站点 1 处于活动状态或正在运行时，ESG 处于电源关闭状态。

过程

  1. 确认主站点 1 上的 NSX Manager 已关闭。
    1. 在安装和升级页面上，导航到管理 (Management) > NSX Manager (NSX Managers)。
      • 如果您在当前的浏览器会话中刷新 NSX Manager 页面，主 NSX Manager 的角色会更改为未知。
      • 如果您从 vSphere Web Client 注销并重新登录，或者启动新的 vSphere Web Client 浏览器会话，NSX Manager 页面上将不会再显示主 NSX Manager。
    2. 导航到网络和安全 (Networking & Security) > 仪表板 (Dashboard) > 概览 (Overview)。
      • 如果您在当前的浏览器会话中刷新仪表板页面，将显示以下错误消息：无法与 NSX Manager 建立连接。请联系管理员 (Could not establish communication with NSX Manager. Please contact administrator.)。。此错误表示无法再访问主 NSX Manager。
      • 如果您从 vSphere Web Client 注销并重新登录，或者启动新的 vSphere Web Client 浏览器会话，NSX Manager 下拉菜单中将不会再提供主 NSX Manager。
  2. 将辅助 NSX Manager 升级到主要角色。
    1. 在安装和升级页面上，导航到管理 (Management) > NSX Manager (NSX Managers)。
    2. 选择辅助 NSX Manager。
    3. 单击操作 (Actions) > 从主 NSX Manager 断开连接 (Disconnect from Primary NSX Manager)。当系统提示是否继续执行断开连接操作时，单击是 (Yes)。
      此时，辅助 NSX Manager 会与主 NSX Manager 断开连接，然后进入 转换角色。
    4. 单击操作 (Actions) > 分配主要角色 (Assign Primary Role)。
      此时，站点 2 上的辅助 NSX Manager 会升级为主要角色。
    小心： 由于在 UDLR 上禁用了本地输出，因此，仅在原始主站点（站点 1）上部署 UDLR 控制虚拟机（Edge 设备虚拟机）。在站点 1 发生故障之前，UDLR 控制虚拟机在辅助站点（站点 2，现已升级为主站点）上不可用。因此，在重新部署 NSX Controller 群集之前，请在升级的主站点（站点 2）上重新部署 UDLR 控制虚拟机。

    如果在部署 UDLR 控制虚拟机之前部署了控制器节点，则会清除 UDLR 上的转发表。这样，在站点 2 上部署第一个控制器节点之后，系统会立即停机。这种情况下可能会导致通信中断。要避免出现这种情况，请先部署 UDLR 控制虚拟机，然后再部署 NSX Controller 节点。

  3. 打开处于关闭电源状态的 NSX Edge 的电源，并在辅助站点 2（升级的主站点）上部署 UDLR 控制虚拟机（Edge 设备虚拟机）。
    有关部署 UDLR 控制虚拟机的说明，请参见 《跨 vCenter NSX 安装指南》。
    部署 UDLR 控制虚拟机时，请配置以下资源设置：
    • 选择站点 2 作为数据中心。
    • 选择群集/资源池。
    • 选择数据存储。
    注： 在部署 UDLR 控制虚拟机后，将会在站点 2 中自动恢复以下配置设置：
    • BGP 协议路由配置
    • BGP 密码配置
    • 上行链路接口和内部接口设置
  4. 在站点 2（升级的主站点）上部署三个 NSX Controller 群集节点。
    有关部署 NSX Controller 的详细说明，请参见 《跨 vCenter NSX 安装指南》。
  5. 更新 NSX Controller 群集状态。
    1. 在安装和升级页面上，单击 NSX Manager (NSX Managers)。
    2. 选择已升级的主 NSX Manager。
    3. 单击操作 (Actions) > 更新控制器状态 (Update Controller State)。
  6. 强制同步站点 2 上每个群集中的路由服务。
    1. 在安装和升级页面上，单击主机准备 (Host Preparation)。
    2. 选择已升级的主 NSX Manager。
    3. 一次选择一个群集，然后单击操作 (Actions) > 强制同步服务 (Force Sync Services)。
    4. 选择路由 (Routing)，然后单击确定 (OK)。
  7. 将工作负载虚拟机从站点 1 迁移到站点 2。
    注： 工作负载虚拟机将继续存在于站点 1 上。因此，您必须手动将该工作负载虚拟机迁移到站点 2。

结果

手动恢复 NSX 组件以及从主站点（站点 1）故障切换到辅助站点（站点 2）的过程已完成。

下一步做什么

通过在站点 2（升级的主站点）上执行以下步骤，确认故障切换到站点 2 的过程已 100% 完成：
  1. 检查 NSX Manager 是否具有主要角色。
  2. 检查是否在 UDLR 上部署了控制虚拟机（Edge 设备虚拟机）。
  3. 检查是否所有控制器群集节点的状态均为已连接。
  4. 检查主机准备状态是否为绿色。
  5. 登录到 UDLR 控制虚拟机（Edge 设备虚拟机）的 CLI 控制台，然后执行以下步骤：
    1. 运行 show ip bgp neighbors 命令检查是否已建立所有 BGP 邻居，并且其状态为“已启动”。
    2. 运行 show ip route bgp 命令检查是否可从所有 BGP 邻居中发现所有 BGP 路由。

在故障切换到站点 2 的过程完成后，所有工作负载在辅助站点（升级的主站点）上运行，并且流量通过站点 2 上的 UDLR 和 NSX Edge 进行路由。