Product Documentation

灾难恢复

可以设计使用主-被故障转移策略的灾难恢复的多个站点的 XenMobile 部署的架构并配置该部署。

本文中探讨的推荐灾难恢复策略由以下几个组件组成:

  • 一个 XenMobile 活动站点,位于一个服务于所有全球企业用户的地理位置的数据中心中,称为“主站点”。
  • 第二个是 XenMobile 站点,位于第二个地理位置的数据中心中,称为“灾难恢复站点”。如果主站点中出现站点范围内的数据中心故障,此灾难恢复站点将提供主动-被动站点故障转移。主要站点包括 XenMobile、SQL 数据库、NetScaler 基础结构以便在与主站点的连接失败时帮助进行故障转移并向用户提供对 XenMobile 的访问权限。

灾难恢复站点中的 XenMobile Server 在常规操作过程中保持脱机状态,并且仅在灾难恢复场景中恢复联机,在该场景中,需要执行从主站点到灾难恢复站点的完整站点故障转移。灾难恢复站点中的 SQL Server 必须处于活动状态并且可随时向连接提供服务,才能在灾难恢复站点启动 XenMobile Server。

此灾难恢复策略依赖 NetScaler 访问层的手动故障转移,通过更改用于在中断时将 MDM 和 MAM 连接路由到灾难恢复站点的 DNS 的方式完成。

注意:

要使用此体系结构,必须具备异步备份数据库的过程以及某些确保 SQL 基础结构的高可用性的方式。

灾难恢复故障转移过程

  1. 如果要测试您的灾难恢复故障转移过程,请关闭主站点中的 XenMobile Server 以模拟站点故障。
  2. 更改 XenMobile Server 的公共 DNS 记录以指向灾难恢复站点的外部 IP 地址。
  3. 更改 SQL Server 的内部 DNS 记录以指向灾难恢复站点的 SQL Server IP 地址。
  4. 在灾难恢复站点使 XenMobile SQL 数据库恢复联机。确保 SQL Server 和数据库处于活动状态并且可以随时用来向从本地 XenMobile Server 到站点的连接提供服务。
  5. 打开灾难恢复站点上的 XenMobile Server。

XenMobile Server 更新过程

每次使用修补程序和发行版本更新 XenMobile 时都请按照以下步骤进行操作,以便保持主服务器和灾难恢复服务器的代码相同。

  1. 确保主站点中的 XenMobile Server 安装了修补程序或者进行了升级。
  2. 确保 SQL Server 的 DNS 记录解析到主站点中的活动 SQL Server 数据库。
  3. 使灾难恢复站点的 XenMobile Server 恢复联机。这些服务器仅在升级过程中通过 WAN 连接到主站点的数据库。
  4. 对所有灾难恢复站点的 XenMobile Server 应用所需的修补程序和更新。
  5. 重新启动 XenMobile Server 并确认修补程序或升级成功完成。

灾难恢复参考体系结构图

下图显示了 XenMobile 的灾难恢复部署的高级体系结构。

灾难恢复参考体系结构图

使用 GSLB 进行灾难恢复

此体系结构的主要元素是使用全局服务器负载平衡 (GSLB) 功能将流量传输到正确的数据中心。

默认情况下,NetScaler for XenMobile 向导将通过不允许使用 GSLB 进行灾难恢复的方式来配置 NetScaler Gateway。因此,必须执行额外的步骤。

GSLB 的工作原理

GSLB 是 DNS 的核心。参与的 NetScaler 设备用作权威 DNS 服务器并将 DNS 记录解析到正确的 IP 地址(通常解析到假定用于接收流量的 VIP)。NetScaler 设备先检查系统运行状况,然后再响应将流量传输到该系统的 DNS 查询。

解析记录时,GSLB 在解析流量中所起的作用将完成。客户端将直接与目标虚拟 IP (VIP) 地址进行通信。DNS 客户端行为在控制记录过期的方式和时间方面具有重要作用。这远远超出了 NetScaler 系统的界限。因此,GSLB 将遵守与 DNS 名称解析相同的限制。客户端缓存响应;因此,通过这种方式进行的负载平衡并不像传统的负载平衡一样实时进行。

NetScaler 上的 GSLB 配置(包括站点、服务和监视器)存在,以便提供正确的 DNS 名称解析。

用于发布服务器的实际配置(在这种情况下,是指 NetScaler for XenMobile 向导创建的配置)不受 GSLB 影响。GSLB 是 NetScaler 上的一项独立服务。

在 XenMobile 中使用 GSLB 的域委派挑战

NetScaler for XenMobile 向导配置 NetScaler Gateway for XenMobile。此向导将生成三个负载平衡虚拟服务器和一个 NetScaler Gateway 虚拟服务器。

其中两个负载平衡虚拟服务器负责在端口 443 和 8443 上处理 MDM 流量。NetScaler Gateway 在端口 8443 上接收 MAM 流量并将其转发到第三个服务器,即 MAM 负载平衡虚拟服务器。所有传输到 MAM 负载平衡虚拟服务器的流量都通过 NetScaler Gateway 传输。

MAM 负载平衡虚拟服务器所需的 SSL 证书与 XenMobile Server 相同,并且使用的 FQDN 与注册设备时使用的 FQDN 相同。MAM 负载平衡服务器还与其中一个 MDM 负载平衡服务器使用相同的端口 (8443)。为使流量能够被解析,NetScaler for XenMobile 向导将在 NetScaler Gateway 上创建一条本地 DNS 记录。该 DNS 记录与用于注册设备的 FQDN 一致。

此配置在 XenMobile Server URL 不是 GSLB 域 URL 时有效。如果 GSLB 域 URL 用作 XenMobile Server URL,就像灾难恢复所需的 URL 一样,本地 DNS 记录将阻止 NetScaler Gateway 将流量解析到 MDM 负载平衡服务器。

使用 CNAME 方法进行 GSLB 灾难恢复

为解决 NetScaler for XenMobile 向导创建的默认配置提出的挑战,可以为父域 (company.com) 中的 XenMobile Server FQDN 创建一条 CNAME 记录,并指向 NetScaler 对其具有权威的委派子区域 (gslb.company.com) 中的记录。这样将允许为解析流量所需的 MAM 负载平衡 VIP 地址创建一条静态 DNS A 记录。

  1. 在外部 DNS 上,为指向 NetScaler GSLB 上的 GSLB 域 FQDN 的 XenMobile Server FQDN 创建 CNAME。需要两个 GSLB 域:一个用于 MDM 流量,另一个用于 MAM (NetScaler Gateway) 流量。

    示例:

    CNAME = xms.company.com IN CNAME xms.gslb.comany.com

  2. 在每个站点的 NetScaler Gateway 实例中,创建一个使用 CNAME 记录指向的 FQDN 的 GSLB 虚拟服务器。

    示例:

    bind gslb vserver xms-gslb -domainName xms.gslb.company.com

    使用 NetScaler for XenMobile 向导部署 NetScaler Gateway 时,请在配置 MAM 负载平衡服务器时使用 XenMobile Server URL。这将为 XenMobile Server URL 创建一条静态 DNS A 记录。

  3. 使用 XenMobile Server URL (xms.company.com) 对在 Secure Hub 中注册的客户端进行测试。

    此示例使用以下 FQDN:

    • xms.company.com 是 MDM 流量使用的 URL,并且由设备注册过程使用,在此示例中是使用 NetScaler for XenMobile 向导配置的。
    • xms.gslb.company.com 是 XenMobile Server 的 GSLB 域 FQDN。