设计决策:灾难恢复规划

概述

本指南有助于规划灾难恢复 (DR) 架构,并考虑本地和云部署 Citrix Virtual Apps and Desktops 的注意事项。
DR 本身就范围广泛而言是一个重要的话题。Citrix 承认,这份文档并不是总体灾难恢复策略的全面指南。它不考虑灾难恢复的所有方面,有时会从外行的角度看待各种灾难恢复概念。

本指南旨在解决对组织的 Citrix 架构有重大影响的这些注意事项,并提供与之相关的架构指导:

  • 业务要求
  • 灾难恢复与高可用性
  • 灾难恢复层分类
  • 灾难恢复选项
  • 云端灾难恢复
  • 操作注意事项

业务要求

与 Citrix 设计方法的“业务层”保持一致,收集精确的业务需求和已知的服务恢复限制,是为 Citrix 制定任何恢复计划的起点。此步骤指导了为灾难恢复策略(稍后讨论)提供信息的范围和要求,这些范围和要求最适合在公司或IT部门确定的限制范围内满足业务和功能需求。

以下是一些在进行灾难恢复规划时需要讨论的有用问题的示例。这些关键组件对于确定业务需求和潜在限制因素非常重要。此清单是常见基准问题的示例,各组织将有其他问题需要回答,以符合其要求。本文档后面的“灾难恢复选项”部分将详细讨论这些问题:

  • 备份策略。备份可以支持灾难恢复,但灾难恢复不能替代备份,实际上,灾难恢复期间需要备份,要么是计划的一部分,要么是作为对冲损坏的复制数据。目前服务器使用什么备份策略?包括:
    • 备份频率?
    • 保留期?
    • 异地存储?
    • 备份测试方法?
  • 恢复时间目标 (RTO)。Citrix 平台是否会在发生灾难时立即可用或在特定时间段内上线?(请参阅灾难恢复层分类)。RTO 因应用或服务关键程度分类而异,但通常,Citrix 的 RTO 必须与在 Citrix 上托管的应用的最低 RTO 相匹配或优于,Citrix 的依赖关系(网络、存储、计算等)必须与 Citrix 的相似或优于 Citrix 的下游 RTO,因为应用程序可能会受到威胁。值得在讨论中加入由 Citrix 托管的应用程序所连接的应用程序后端,以保持期望。

  • 恢复点目标 (RPO)。对于 RPO,组织认为可以容忍多大程度的数据丢失,具体取决于相关应用程序的分类?该服务的恢复数据可以保留多久?0 分钟?一个小时?一个月?在 Citrix 基础架构的上下文中,此考虑因素仅适用于数据库更改和用户数据(配置文件、文件夹重定向等)。与 RTO 一样,值得考虑 Citrix 托管应用程序的应用程序后端。

  • 追回范围。这种考虑因素不仅包括 Citrix 基础架构,还可能包括 Citrix 托管的应用程序客户端与之交互的用户数据或关键应用程序服务器。确定恢复 Citrix 平台的时间与恢复 Citrix 上托管的应用程序的时间之间是否存在差异非常重要。时间增量可以延长停机时间,因为只有解决方案的一部分。

  • 使用案例。Citrix 平台通常为许多用例提供服务,每个用例的业务关键程度都不同。恢复是否涵盖所有 Citrix 使用案例?或者是企业运营成功完全依赖的关键用例。答案对基础设施范围界定和容量预测有很大影响。如果灾难恢复是 Citrix 环境的一项全新功能,则建议对用例进行分层和优先排序,以区分灾难恢复的启用情况。

  • 能力。是否有任何不需要在灾难恢复中包含的关键功能可以降低成本?此功能的一个例子是使用永久桌面与非永久桌面;某些 VDI 用例可以由托管共享桌面甚至特定的应用程序单独提供。组织有时表示在灾难恢复中不需要组件冗余(ADC、Controller、StoreFront、SQL 等)如果长期停产,这种决定可被视为风险。

  • 现有博士其他 Citrix 环境和其他基础结构服务是否存在现有的 DR 策略或计划?它是恢复到新的可路由子网中还是进入映像生产网络的“泡沫”?答案有助于提供当前灾难恢复方法、工具或优先级的可见性。

  • 技术能力。这种考虑并不能决定 Citrix 的最终恢复策略。但是,了解以下内容很重要:
    • 恢复: 组织内部提供哪些存储复制技术、VM 恢复技术(VMware SRM、Veeam、Zerfor、Azure 站点恢复 (ASR) 等)?Citrix 依赖项以及一些 Citrix 组件可以使用它们。

    • Citrix: 哪些 Citrix 技术用于映像管理和访问?某些组件不适合某些恢复策略。由 MCS 或 PVS 管理的非持久环境不适合使用虚拟机复制技术,因为它们与存储和网络紧密集成。

  • 数据严重程度。用户配置文件或用户数据是否被认为对恢复至关重要?对于持久 VDI,如果调用 DR 时这些数据不可用,这会对工作效率造成重大影响吗?或者是否可以将非持久性配置文件或 VDI 用作临时解决方案?此决定可能会增加成本和解决方案的复杂性。

  • 灾害类型。此决定相当重要,但也可以通过公司 BC 或灾难恢复计划预先确定。此要求通常决定了恢复位置。该策略是否仅适应应用程序级别的服务恢复?在硬件机架之间?在地铁位置内?在两个地理区域之间?两个国家?在云提供商区域或整个云提供商的基础设施(多区域)中?在云提供商(多云)之间?

  • 客户端用户。在生产环境中访问服务的用户在哪里?此决定可能会对服务恢复到何处产生影响,包括公司网络连接,这可能需要在灾难恢复事件期间进行手动修改。此外,答案决定了访问层的注意事项。

  • 网络带宽。每个用户会话平均消耗多少流量(ICA,应用程序,文件服务)?此决定既适用于云恢复,也适用于本地恢复。

  • 回退(或故障回退)。一旦灾难恢复情况得到解决,组织是否已经制定了如何恢复生产服务的预先计划?组织如何恢复到正常状态?如何在灾难恢复中创建的新数据与生产数据进行协调和合并?

限制

限制条件限制了灾难恢复设计选项或其配置。它们有多种形式,但可能包括:

  • 监管或公司策略。这个决定可以决定哪些技术可以或不能用于复制或恢复、如何使用它们、RTO、数据主权或设施之间的最小距离。

  • 基础设施。是否有关于要使用的硬件类型、可用网络带宽等的指令?这些考虑可能会影响 RPO 考虑因素,甚至可能带来风险。例如:
    • 灾难恢复中的防火墙或网络管道过小最终会导致中断,因为网络依赖关系无法处理灾难恢复工作负载。
    • 就计算而言,规模过小的虚拟机管理程序主机或使用不同的虚拟机管理程序会完全影响选项。
    • 关于网络,在为 WAN 提供服务时,如果恢复站点的网络吞吐量能力与生产相比受到的限制更大。
    • 在云环境中,尤其是在扩展到数千个席位时,由于虚拟防火墙、VPN 网关和云到 WAN 的上行链路(AWS Direct Connect、Azure ExpressRoute、Google Cloud Interconnect 等)等组件服务限制,这种潜在风险很快就会成为一个严重的瓶颈。
    • 此外,在云环境中,还要适当考虑灾难恢复区域中指定的云区域中可用的服务的同等性。该领域的经验告诉我们,尽管从托管成本的角度来看,公有云区域最初似乎很有吸引力,但可用区、实例类型或特定存储功能等重要功能并非在所有云区域都可用。一个好的经验法则是评估计划使用的功能和功能是否在计划部署的所有地区都可用。
  • 预算。灾难恢复解决方案的成本可能与项目预算相冲突。通常,RTO 越短,成本就越高。

  • 地理学。如果已确定指定的灾难恢复设施,则必须了解从生产到灾难恢复设施的延迟以及用户连接到灾难恢复等考虑因素。

  • 数据驻留或数据分类。此决定可能会限制区域和技术或恢复方法的选项。

  • 云恢复。是否强制要求在云端恢复基础架构,而不是在本地设施中恢复基础架构?

  • 容量。灾难恢复位置是否有足够的容量来处理满足灾难恢复要求所需的负载?如果恢复到云端,如果没有预先配置或有保障的容量授权,那么需要在 RTO 内恢复的工作负载量是否现实?

  • 应用准备状态。托管在 Citrix 上且具有后端依赖关系的应用程序是否有灾难恢复计划?RTO 如何与 Citrix 的目标 RTO 保持一致?Citrix 可以用于快速恢复,但是如果核心应用程序没有恢复计划或具有扩展 RTO 的恢复计划,则此风险可能会影响 DR.

  • 网络安全。组织是否有可能规定哪些流量段在传输过程中需要加密的安全策略?这个考虑因素是否因所遍历的网络链路而有所不同?答案可能需要在灾难恢复方案中使用 SSL VDA、ICA 代理、GRE 或 IPsec VPN 封装 ICA 流量,如果灾难恢复的网络流量不同于生产流量。

对灾难恢复 (DR) 设计的误解

Citrix DR 设计中最常见的误解之一是,跨越两个数据中心的单个控制平面构成了 DR。它没有。
跨越数据中心的单个 Citrix 站点或 PVS 场包括高可用性设计,但不包括灾难恢复设计。
一些组织选择这条路径作为业务决策,他们更看重简化的管理而不是灾难恢复能力。仅在连接良好(低延迟)的数据中心之间 支持 跨数据中心的 StoreFront 服务器组。同样,PVS 记录了跨数据中心部署时需要考虑的最大延迟,如 CTX220651 中所述。

下图是多数据中心 HA Citrix 架构的示例,但由于前面提到的理由,该架构不是灾难恢复平台。这种参考架构适用于将两个物理上独立的数据中心设施视为单个逻辑数据中心的组织,因为它们彼此靠近,而且延迟低、带宽高。仍然建议使用 Citrix 的灾难恢复计划和环境,因为此体系结构不太可能满足灾难恢复或高可用性的需求。

灾难恢复

除了上面的 HA 概念参考之外,基于区域的高可用性架构还适用于想要提供跨地域冗余但又不要求平台完全可恢复的组织。区域概念允许使用各种站点内冗余功能,从而解决多地点部署的难题。

在使用 区域首选项 功能的站点架构中,相同的 Citrix 资源部署在多个区域中,并聚合到一个交付组中。可以根据应用程序、用户的主区域或用户的位置来控制区域首选项(能够回切到给定资源的其他区域)。有关此主题的详细信息,请参阅 区域首选项内部VDA 注册自动更新功能允许 VDA 维护站点内所有控制器的本地缓存的最新列表。此功能允许卫星区域内的 VDA 在本地区域不可用时将其本地 Delivery Controller 或 Cloud Connector 的注册故障切换到主区域。StoreFront 服务器组存在于每个区域位置(或至少在两个区域中),建议用户在主区域不可用时继续从本地访问层访问资源。

灾难恢复

与这些受支持的高可用性选项相比,下图显示了跨地理位置遥远的数据中心或云区域的不受支持或不明智的组件架构。由于组件之间的距离和延迟,这些图表既不能提供有效的高可用性也无法提供灾难恢复。由于此类部署中的延迟问题,也可能导致平台稳定性问题。此外,站点之间管理边界的拉伸与 DR 主体不一致。过去,我们见过组织类似的概念设计。

灾难恢复

另一个常见的误解是 Citrix DR 解决方案可以考虑的深度。Citrix Virtual Apps and Desktops 的核心主要是一个 演示和交付平台。Citrix 控制平面取决于其他组件(网络、SQL、Active Directory、DNS、RDS CAL、DHCP 等),这些组件自己的可用性和恢复设计满足 Citrix 平台的灾难恢复要求。Citrix 所依赖的技术的任何共享 管理 域都会影响 Citrix DR 解决方案的有效性。

Citrix 托管的应用程序和桌面与之接口的文件服务(共享上的用户数据和业务数据等)以及应用程序后端的恢复注意事项,组织有时也不会完全考虑。引用早期应用程序准备情况时,Citrix DR 平台可设计为在短时间内恢复。但是,如果这些核心用例依赖关系没有类似于 Citrix 的 RTO 恢复计划,或者根本没有恢复计划,则该计划可能会影响 Citrix 按预期在灾难恢复中成功进行故障转移,但由于这些依赖项仍然不可用,用户将无法完成其工作职能。例如,在 Citrix 上托管其核心 EMR 应用程序的医院。发生灾难恢复事件,Citrix 故障转移到灾难恢复中的“始终开启”的 Citrix 平台,用户正在连接,但是 EMR 应用程序是通过更多手动方式恢复的,可能需要数小时或数天才能完成。在此期间,临床工作人员可能会被迫使用离线流程(笔和纸)。这样的结果不可能符合企业对恢复时间或用户体验的总体预期。

下一节将更详细地讨论灾难恢复与高可用性。

灾难恢复 (DR) 与高可用性 (HA)

了解 HA 与灾难恢复对于与组织需求保持一致和实现恢复目标至关重要。HA 不是 DR 的代名词,但 DR 可以使用 HA。本指南对高可用性和灾难恢复的解释如下:

  • HA 被视为为系统(服务、应用程序等)或组件提供容错能力。一个系统可以故障转移到另一个系统,而对用户的干扰最小。该解决方案可以像群集或负载平衡应用程序一样简单,也可以是更复杂的主动或备用“热”或“永远开启”基础架构,后者映像生产配置并始终可用。在这些配置中,故障转移往往是自动化的,也可以称为“地理冗余”部署。
  • 灾难恢复主要关注将服务恢复到备用数据中心(或云平台)的服务(由于严重的应用程序级故障或数据中心的灾难性物理故障)。灾难恢复往往涉及自动或手动恢复过程。记录步骤和过程以协调恢复。它与组件的冗余或容错性无关,通常是一种范围更广的策略,可以承受多种类型的故障。

虽然高可用性往往嵌入到设计规范和解决方案部署中,但灾难恢复主要涉及调用服务恢复的 IT 人员和基础设施资源的协调规划。

医管局能否包括 DR?是。对于企业任务关键型 IT 服务,这种概念很常见。以前面的 HA 描述中的第二个示例为例,再加上与该解决方案相关的其他非 Citrix 组件的适当恢复,这将被视为一种高度可用的灾难恢复解决方案,其中服务 (Citrix) 故障转移到对方的数据中心。该架构可以在各种多站点迭代中实现主动-被动或主动-主动,例如适用于所有用户的主动-被动,用户更喜欢一个数据中心而不是另一个数据中心的主动-主动,或者在两个数据中心之间进行负载平衡的主动-主动,用户可以不偏好在两个数据中心之间进行负载平衡。值得注意的是,在设计此类解决方案时,必须考虑、考虑备用容量,并持续监视负载,以确保在需要时仍有容量可以容纳灾难恢复。

还必须使灾难恢复组件与生产保持同步,以保持解决方案的完整性。这些组织往往会忽视这项活动,他们本着最好的意图设计和部署这样的解决方案,然后开始在生产中消耗更多的平台资源,却忘记增加可用容量来保持解决方案的灾难恢复完整性。

在 Citrix 的背景下,在两个数据中心之间跨越 Citrix 管理域(Citrix Site、PVS Farm 等),例如根据已发布的指南进行地理定位的两个设施,并不能构成灾难恢复,也无法构成某些组件(例如 StoreFront 服务器组)的灾难恢复。同样,由于 PVS 根据已发布的指南存在数据库延迟限制,因此不建议进行此类部署。地理位置之间的支持性限制还延伸到Citrix站点和区域设计,因为根据已发布的指南,卫星控制器和数据库之间的最大延迟。

由于许多 Citrix 组件共享依赖关系(如数据库),因此在两个数据中心之间延伸管理边界无法防范多种关键故障情况。如果数据库损坏,故障域将影响两个设施的应用程序服务。为了将高可用性 Citrix 解决方案视为足以实现灾难恢复,我们建议第二个设施不要共享密钥依赖关系或管理边界。例如,为解决方案中的每个数据中心创建单独的站点、场和服务器组。通过使恢复平台尽可能独立,我们可以减少组件级故障对生产和灾难恢复环境的影响。这种考虑还超出了 Citrix 的范围,还建议在生产和灾难恢复环境之间使用不同的服务帐户、文件服务、DNS、NTP、虚拟机管理程序管理、证书颁发机构(FAS 依赖关系)和身份验证服务(AD、RADIUS 等),以减少单点故障。

灾难恢复层分类

灾难恢复的层级分类是组织灾难恢复策略的重要方面,因为它们可以清楚地了解应用程序或服务关键程度,这反过来又决定了 RTO(以及实现该恢复级别的成本)。或者,一些组织会建立支持的 RTO(由技术解决方案或架构模型支持)并为其分配层级分类。通常,RTO 越短,灾难恢复解决方案的成本就越高。能够将各种相互依赖关系分解为不同的分类(基于业务关键性和 RTO)有助于优化成本敏感的 DR 案例。

以下是一组灾难恢复层分类示例,可在评估 Citrix 上托管的 Citrix 基础架构服务、其依赖关系以及关键应用程序或用例(与 VDA 工作负载相关联)时作为参考。灾难恢复层按恢复优先级顺序列出,其中 0 表示最重要。鼓励组织应用或开发与自己的恢复目标和分类需求保持一致的灾难恢复分层分类。

第 0 层灾难恢复(示例)

第 0 级-恢复目标

恢复时间目标:0

恢复点目标:0

第 0 级-分类

核心 IT 基础架构

  • 网络和安全基础设施
  • 网络链接
  • 虚拟机管理程序和依赖项(计算、存储)

核心 IT 服务

  • Active Directory
  • DNS
  • DHCP
  • 文件服务
  • RDS 许可
  • CA 服务(如果使用 FAS)
  • SQL 服务器(本地 WEM 或 Citrix Virtual Apps and Desktops、PVS、Session Recording)
  • 关键最终用户服务 (Citrix)

第 0 级-备注

这种分类主要针对核心基础设施组件。这些组件始终在灾难恢复位置可用,因为它们是其他层的依赖关系,而不是在隔离的网段中。它们需要与其生产等效物一起进行配置和维护。如果 Citrix 托管关键应用程序,则可能被视为第 0 层平台。在这种情况下,Citrix 基础架构在 DR.

第 1 层灾难恢复(示例)

第 1 级-恢复目标

恢复时间目标:15 分钟

恢复点目标:1 小时

第 1 级-分类

关键应用程序

  • 网站和网络应用程序
  • ERP 和 CRM 应用程序
  • 业务线应用程序

Citrix 使用案例

  • 管理
  • 呼叫中心
  • 客户服务或销售
  • IT 工程与支持

第 1 级-备注

企业开展核心业务活动所依赖的应用程序或虚拟桌面通常包含在此层中。他们可能还会使用类似于第 0 层的“热备用”灾难恢复体系结构,或者受益于自动化复制和故障转移解决方案。如果配置到云端( 稍后将讨论这些注意事项),则需要考虑在内,因为它们可能会影响 RTO 目标。

第 2 层灾难恢复(示例)

第 2 级-恢复目标

恢复时间目标:4 小时

恢复点目标:1 天

第 2 级-分级

非关键应用程序

非关键的 Citrix 用例

不影响第 1 层或第 0 层应用程序功能的用户数据

第 2 级-备注

对业务运营至关重要的应用程序或使用情形,但其短期内不可用性不太可能对财务、声誉或运营造成严重影响。这些应用程序要么从备份中恢复,要么通过自动恢复工具以最低优先级恢复。

第 3 层灾难恢复(示例)

第 3 级-恢复目标

恢复时间目标:5 天

恢复点目标:1 周

第 3 级-分级

不常使用的应用程序

第 3 级-备注

停机影响可以忽略不计的应用程序在长达一周的时间内不可用。 这些应用程序可能会从备份中恢复。

灾难恢复第 4 层(示例)

第 4 级-恢复目标

恢复时间目标:30 天

恢复点目标:24 小时或无

第 4 级-分级

非生产环境

第 4 级-备注

中断对业务运营的影响也微乎其微的应用程序、基础架构和虚拟数据交换机可以随着时间的推移而恢复。根据其性质,他们也可以拥有延长 RPO,也可以完全不延长 RPO。这些 RPO 可以从备份中恢复,也可以在灾难恢复中全新构建,被视为要恢复的最后一层。

为什么层分类对 Citrix 灾难恢复计划很重要

层分类对于 Citrix 非常重要,原因如下:

  • Citrix 基础结构对于业务运营的重要性有多大?如果 Citrix 被认为是必不可少的,但其主机应用程序被认为是必要的,那么 Citrix 基础架构将被归类为关键基础架构。
  • Citrix 托管的用例或核心业务应用程序。它们有不同的灾难恢复等级分类吗?

对于第一个问题,由于交付了关键应用程序或桌面,许多企业 Citrix 部署往往被归类为第 0 层;“永远在线”层,例如网络、Active Directory、DNS 和虚拟机管理程序基础架构。但是,对于每个 Citrix 用例来说,情况并非总是如此。如果某些用例可能属于第 1 层或更高层,则将每个 Citrix 用例视为第 0 层可能会影响灾难恢复过程的总体成本和复杂性。

第二个问题强调按照 Citrix 用例进行分类,并强调其在云环境中的重要性,稍后将详细讨论。在云中,在适应“永远在线”的应用程序或桌面平台与被认为对业务不太重要的应用程序或桌面之间,需要考虑大量的成本因素。这些考虑因素还会影响生产中的应用程序或使用案例隔离(孤岛),以利用灾难恢复平台中的部署灵活性。

在为 Citrix 制定灾难恢复设计时,将讨论置于 Citrix 本身的范围之外有助于设定对业务部门的期望。例如,Citrix 环境被视为“永远在线”的服务,并且在备用数据中心中具有很高的可用性。但是,调用恢复后,Citrix 托管应用程序所依赖的关键后端将在几个小时内保持不可用。这种差距造成了两个平台之间的恢复时间差异,并可能在恢复过程中提供误导性的用户体验。Citrix 可立即使用,但关键应用程序无法运行。从一开始就设定期望可以让所有利益相关者适当了解复苏经历。在某些情况下,客户可能希望在对方设施中保持 Citrix 的热备用状态(始终处于开启状态),但要手动控制接入层的故障转移,以避免对平台可用性的误解。

灾难恢复选项

本节概述了常见的 Citrix 恢复策略,包括其优缺点和关键注意事项。Citrix 可能具有其他恢复功能或以下主题的变体。本节重点介绍一些最常见的内容。此外,本节还说明了早期对 核心问题的回应如何影响 DR 设计。

与之前的几个灾难恢复问题相关的是,以下问题主题对 Citrix 灾难恢复设计有影响,如下所示:

  • 备份策略和恢复时间目标 (RTO)。如果 Citrix 基础架构或由 Citrix 提供的应用程序被视为任务关键型,那么 Citrix 很可能必须采用“永远在线”模式,即两个或更多数据中心存在热备用或主动-主动 Citrix 基础架构。此体系结构将导致在每个数据中心创建多个独立的 Citrix 控制平面(单独的 Citrix 站点、PVS 场(如果适用)、StoreFront 服务器组等)。跨越Citrix基础架构的控制平面并不能构成灾难恢复(例如,跨越数据中心的站点或使用卫星区域);如果企业期望为Citrix提供灾难恢复平台,则这样做与该要求背道而驰。
  • 追回范围。如果 Citrix 在灾难恢复中以热备用(始终开启)容量部署,但核心业务应用程序后端需要 8 小时才能恢复,那么采用自动访问层故障转移就没有意义了。访问层的手动故障切换可能更为合适。
  • 使用案例。如果只有关键工作负载或核心应用程序必须在 Citrix 中快速恢复才能在灾难恢复方案中维护业务运营,则从容量角度来看,此方案可能会降低灾难恢如果多个优先级不同的用例需要恢复,那么根据前面讨论的恢复分层策略,将每个用例的重要性分类与业务影响进行对比,并不能降低容量成本,但可以为IT人员提供一组更有针对性的恢复优先顺序。
  • 能力。如果某些组件(例如 HDX Insight 和 Session Recording)被认为对灾难恢复平台的运行不重要,那么在灾难恢复环境中省略这些组件可以消除一些复杂性和维护开销。同样,如果灾难恢复方案中的许多使用案例可以依靠灾难恢复中更简单、更通用的 Citrix 交付选项,这也可以降低复杂性和成本。例如,如果技术上可行,则使用托管共享桌面代替池化 VDI 或持久 VDI(在灾难恢复场景中快速且经济实惠的服务恢复背景下),或者将更多用例聚合为一个,前提是它们不会对业务运营造成损害。 灾难恢复
  • 现有博士例如,如果组织的现有灾难恢复策略使用数据复制和编排工具恢复 Citrix 和其他应用程序基础架构,则大多数 Citrix 组件可能适用于此模型。如果平台的大小和对单映像管理技术的依赖是生产平台的要求,那么此类技术通常不合适;采用热备用 Citrix 平台和主映像复制的混合方法可能更合适。
  • 数据严重程度。如果认为配置文件对灾难恢复至关重要,则可能需要适当的复制技术。许多组织不太关心灾难恢复场景中的配置文件,而是接受重新创建配置文件。此考虑也适用于 Citrix 中访问的用户数据(文件夹重定向、映射驱动器);此数据的 RPO 和 RTO 可能是业务决策。此外,如果许多永久性虚拟磁盘被认为足够重要,足以在灾难恢复中保持不变(而不是要求用户重新安装软件等),则必须考虑复制这些虚拟机,这可能会产生额外的成本来支持恢复。
  • 灾害类型。客户希望在多大程度上防范故障可能会决定各种体系结构更改。如果客户只想在数据中心或云区域内使用 Citrix 基础架构的高可用性,则此类灾难只需要确保管理组件冗余且在对立的基础架构上运行。例如,一种 StoreFront 服务器对使用 VMware 反关联性规则在群集中的不同主机上运行,或者完全在数据中心内的不同群集上运行,或者可能作为不同可用性集的一部分运行。这种情况很少需要完全创建冗余控制平面(例如多个 Citrix 站点和 StoreFront 服务器组)。但是,如果灾难恢复旨在涵盖多个数据中心,无论区域如何,则在每个数据中心使用本地依赖关系(AD、DNS、SQL、虚拟机管理程序等)的冗余控制平面更为合适。如果客户是全球性的,并且使用多个数据中心为 Citrix(或计划)提供服务,并将相应的应用程序后端到这些数据中心,则更有可能使用地理本地化的主动 HA-DR 体系结构更为合适。该架构通过使用地理定位的 Citrix 基础架构,尽可能为用户提供最佳的用户体验,如果需要,可以按次要优先顺序故障转移到备份数据中心。
  • 客户端用户。除了前面关于用户、应用程序和数据本地化注意事项的观点外,一些客户端用户网络还可能被安全设备(代理、防火墙等)相对封锁,这些设备可以限制与 Internet 甚至广域网的出站通信。务必考虑此状态是否适用于客户网络,并确保在其本地安全配置中考虑到 Citrix 服务(例如 StoreFront VIP 和 VDA IP 或 Citrix Gateway IP)的新 IP,以确保在调用 DR 时不会由于本地局域网安全限制而出现进一步的恢复延迟从准备的角度来看,在灾难恢复的情况下,客户端访问是否会以某种方式改变?例如,在某些灾难恢复场景中,组织可以假设广域网不可用,所有用户都必须通过 Internet 访问 Citrix 资源。此类步骤需要在灾难恢复和就绪计划中记录下来,为最终用户确定先决条件(关于支持的Citrix客户端详细信息以及企业或自带设备访问权限的假设),以消除用户恢复服务的障碍,从而进一步减轻支持台的负担。
  • 网络带宽。VDA 流量(ICA、应用程序、文件服务)所使用的网络带宽量必须考虑灾难恢复设施网络规模和防火墙。在 VPN 网关和虚拟防火墙容量存在限制的云环境中,这一考虑因素尤为重要。监视来自 VDA 的生产流量以确定大小的平均值对于有效调整网络大小非常重要。如果存在网络限制,则组织必须使用不同的网络配置来适应预期的灾难恢复流量负载。
  • 回退(或故障回退)。如果灾难恢复中的用户数据发生了变化,或者灾难恢复期间的 VDA 映像已更新,则如果生产环境证明可以恢复,组织必须做好故障恢复计划,以便将这些更改传播回生产环境。对于用户数据,它可以像反转复制顺序和恢复一样简单;同样,对于 Citrix 基础架构(如果不使用单一映像管理技术)。如果使用 MCS 或 PVS,则可以将主映像或虚拟磁盘手动复制回生产环境,并相应地更新 VDA。

以下列表概述了 Citrix 的各种常见恢复选项。每个选项的改编都存在于现场(组织有时会选择仅实施这些选项中的一部分以将灾难恢复限制在关键用例中,或者使用混合选项在用例层之间平衡成本),但是为了进行比较,我们概述了每个选项的基本版本。这些选项从最简单(通常更高的 RTO 和更低的成本)开始,通过更高级的 RTO(通常较低的 RTO 但成本更高)。对于给定组织来说,理想的选择是,除了可用的 IT 技能、预算和基础架构之外,还与托管应用程序或使用案例的恢复时间保持一致。

此外,尽管可以实现,但许多选项表明,与网络和存储集成的 Citrix 技术(例如 NetScaler 和单映像管理技术)不适合“始终开启”恢复模式以外的方法。这并不是说从技术上讲是不可能实现的,但实现这些目标所涉及的复杂程度会使恢复风险更大,而且更容易出现人为错误。

恢复选项-从脱机备份中恢复

在此选项中,组织仅依靠传统的备份解决方案将 Citrix 平台恢复到其他地点使用。没有可供故障转移的备用基础架构。恢复计划中需要执行多项手动任务,才能恢复 Citrix 所依赖的核心服务,然后恢复 Citrix 本身。Citrix 的停机时间取决于在灾难恢复位置恢复组件的速度。这种模式不适合高级 Citrix 部署,最适合规模更小、更简单的基础架构和能够承受长时间停机的组织。

灾难恢复

优点和缺点

优点:

  • 与复制或热备用解决方案相比,维护成本更低

缺点:

  • 停机时间影响大
  • 更大、更详细的恢复计划 (DR 编排) 文档
  • 恢复时间延长
  • 依赖于备份的完整性和期限
  • 如果需要手动重新配置(网络等),则人为错误的程度会更高
  • 不适合池化、快速克隆 MCS 或 PVS
  • 由于网络原因,不适合 NetScaler VPX(需要使用 nsconfig 目录和 ns.conf 文件的备份进行重建)
  • 必须考虑充分扩大备份保留范围,以适应其他现代威胁,例如定时轰炸和勒索软件

使用案例和假设

对于不太成熟的 IT 组织和 IT 运营预算有限的组织非常有用,可以允许延长停机时间以恢复核心业务服务。假设定期对备份和恢复过程进行测试,以确保备份良好,并且必须在真实事件中进行恢复的人也能很好地理解恢复过程。

恢复选项-通过复制恢复

此选项与之前的选项类似,但使用复制而不是备份来恢复基础架构。复制可以减少恢复序列中手动任务的某些方面,并有可能降低 RTO(从而更快地恢复服务),但仍然依赖于许多手动任务。值得注意的是,复制并不能取代备份。损坏或受损的数据仍会被复制到灾难恢复,因此在这种情况下没有用。仍必须将备份视为备用备份。与之前的选项一样,此模型不适合高级 Citrix 部署,最适合更小、更简单的基础架构和能够承受长时间停机的组织。

灾难恢复

优点和缺点

优点:

  • 复制很可能是自动化的,并且与 RTO 和 RPO 保持一致
  • 与自动恢复解决方案相比,可能使用不太复杂的技术

缺点:

  • 依靠行政干预
  • 更大、更详细的恢复计划 (DR 编排) 文档
  • 如果需要手动重新配置(网络等),则人为错误的程度会更高
  • 不适用于池化、快速克隆 MCS 或 PVS。计算机目录的复制已纳入预计的 RTO 中。但是,通过在灾难恢复中创建虚拟计算机目录或在 DR 中扩展 VDA 实例,然后执行应用复制的主映像的“更新目录”操作,可以缩短此 RTO
  • 由于联网的原因,不适合 NetScaler VPX,因此更适合使用热备用 NetScaler 并承担这样做的成本

使用案例和假设

适用于不太成熟的 IT 组织和 IT 运营预算有限的组织。该解决方案依靠SAN供应商或虚拟机管理程序供应商(vSphere Replication、Nutanix Replication等)提供的存储复制技术,通过广域网将虚拟机复制到另一个设施。

恢复选项-使用自动恢复进行复制

在此选项中,为解决方案的多个组件引入了自动恢复,以恢复 Citrix 基础架构及其在灾难恢复位置的依赖关系。协调自动恢复的技术进一步减少了手动步骤,最大限度地减少了人为干预(以及潜在的人为错误),并且可以通过简化服务恢复来进一步改善 RTO。预计仍需要进行干预,才能通过修改 DNS 记录将故障转移到灾难恢复位置。值得注意的是,复制并不能取代备份。损坏或受损的数据仍会被复制到灾难恢复,因此在这种情况下没有用。备份仍被视为备用备份。尽管这种模式更加成熟,但它仍然不适合与高级 Citrix 配置一起使用,也不适合无法容忍大量停机的组织。

灾难恢复

优点和缺点

优点:

  • 与热待机解决方案相比,维护成本更低
  • 复制可能是自动化的,并与 RTO 和 RPO 对齐
  • 恢复计划往往是自动化的
  • 减少管理干预和人为错误

缺点:

  • 依靠 VMware SRM、Veeam、Zerto、Nutanix Disaster Recovery Orchestration、XenServer 灾难恢复和 Azure 站点恢复 (ASR) 等更先进的技术来协调恢复和修改网络参数(除非网段延伸)
  • 不适用于池、快速克隆 MCS 或 PVS。计算机目录的复制必须纳入预计的 RTO。但是,通过在灾难恢复中创建虚拟计算机目录或在 DR 中扩展 VDA 实例,然后执行应用复制的主映像的“更新目录”操作,可以缩短此 RTO
  • 由于网络原因,不适合 NetScaler VPX,因此更适合使用热备用 NetScaler

使用案例和假设

对于拥有适当资源和灾难恢复设施预算的企业组织非常有用。此解决方案依赖于与前一个选项相同的存储复制,但包括灾难恢复编排技术,用于按特定顺序恢复虚拟机、调整 NIC 配置(如果需要)等。

恢复选项-带手动故障转移的热待机(主动-被动)

现在,我们开始研究使用热备用基础设施的选项。尽管成本更高,但适当设计的热备用模式的优点大大减少了协调灾难恢复位置恢复所需的步骤数量,降低了技术和人为错误的风险,并且可以显著缩短恢复时间。这些模型确实需要维护独立的 Citrix 基础架构,这会带来更多的开销(持续的维护和测试),但可以适应使用单一映像管理技术的更高级的 Citrix 部署。在此选项中,故障转移依赖于管理员的干预,通过 DNS 更改将流量重定向到备用位置,从而降低访问层自动故障转移的成本和复杂性。此选项最适合预算足以容纳备用 Citrix 基础架构、依赖高级 Citrix 配置、需要低 RTO 但需要手动控制恢复的组织。

灾难恢复

优点和缺点

优点:

  • 由于平台“始终开启”,因此恢复时间短
  • 支持存储和依赖网络的组件,例如 NetScaler、MCS、PVS
  • 较低的恢复计划(灾难恢复编排)文档

缺点:

  • 依靠管理干预来故障切换 URL 或指导用户备份 URL(尽管手动编排有时是故意的)
  • 由于灾难恢复中的“热”硬件处于待机状态,因此成本更高
  • 更高的管理开销,保持备用平台的配置和更新与生产同步

使用案例和假设

对于拥有适当资源和灾难恢复设施预算的企业组织非常有用。可以使用热备用“完全扩展”平台或“按需扩展”平台。后者可能对云恢复具有吸引力,以降低运营成本,但 有一些警告

在故障转移时,管理员更新一个或多个访问 URL 的 **DNS** 条目,使其指向 Citrix Gateway 和 StoreFront 的一个或多个灾难恢复 IP,或者通过正式通信建议用户开始使用“备份”或“灾难恢复”URL。

此手动选项对于应用程序后端可能需要更长的恢复时间但如果 Citrix 完全可用且应用程序未完全可用,则会给用户造成混乱的情况非常有用。

此模型假设一个成熟的 IT 组织以及足够的 WAN 和计算基础架构可用来支持故障转移。

恢复选项-具有自动故障转移功能的热待机(主动-被动)

与之前的热备用选项类似,此选项包括自动故障转移,通常通过 DNS 技术进行故障转移,该技术可检测生产中的故障并将流量重定向到 DR 位置。自动化性质确实进一步强调了IT团队的重视,以确保在灾难恢复和应用程序中适当维护配置,并且在正常运行期间可以从灾难恢复中访问数据依赖关系,以避免因生产中孤立的临时服务中断而可能进入灾难恢复站点的用户受到影响。由于自动故障转移功能,容量管理和监视(确保灾难恢复可以容纳 Citrix 上与生产相同数量的用户)变得越来越重要。此选项最适合预算足以容纳备用 Citrix 基础架构、依赖高级 Citrix 配置且要求接近零的 RTO 的组织。

灾难恢复

优点和缺点

优点:

  • 由于平台“始终开启”,因此恢复时间短
  • 支持存储和依赖网络的组件,例如 NetScaler、MCS、PVS
  • 最小恢复计划(DR 编排)文档
  • 由于 URL 故障转移,最终用户更容易
  • 使用 GSLB 支持 Citrix Gateway 的 EPA 扫描

缺点:

  • 由于灾难恢复中的“热”硬件处于待机状态和 NetScaler 许可,因此成本更高。如果将备用容量用于开发或其他不太重要的非生产工作负载(可以在灾难恢复期间关闭电源以确定生产恢复的优先级),则可以在一定程度上减轻成本负担
  • 更高的访问层复杂性
  • 使备用平台的配置和更新与生产同步所需的管理开销更高

使用案例和假设

企业组织的常见配置,允许通过 NetScaler GSLB 自动故障转移到灾难恢复站点(需要高级或更高版本)。此模型假设一个成熟的 IT 组织以及足够的 WAN 和计算基础架构来支持故障转移。该模型还假设应用程序和用户数据依赖关系与最新的活动站点版本/更新保持一致,并且可以以类似的自动化方式在灾难恢复设施中恢复,以减少服务对最终用户的长期影响以及由于解决方案部分功能而造成的混乱。

恢复选项-主动-主动与自动故障转移

此选项建立在前者的基础上,但在常规操作期间,生产和灾难恢复位置都处于活动状态。容量可以得到严格管理和监视,因为在这样的模型中,当任一位置超过阈值(例如 40-45% 的使用率)时,更容易被忽视,以确保任一位置都能在灾难恢复事件期间容纳全部用户负载。由于这两个环境都被积极使用,因此内置了对大多数组件的例行验证。 但是,需要故障转移到灾难恢复位置的组件(应用程序、存储阵列等)仍会定期进行例行故障转移测试。由于模型使用两个或多个活动位置,因此必须考虑性能容差和位置之间的差异,尤其是在这些位置跨越很长的地理距离的情况下。在此模型中,通过在常规操作期间将用户重置到一个位置而不是另一个位置(本地化 VDA),并在其本地位置不可用时故障转移到其他 VDA,可以最大限度地减少某些性能偏差。该模型最复杂、最强大,可容纳最高级的 Citrix 部署。它非常适合那些需要 RTO 为零,并且希望在灾难恢复事件期间只有 50% 的用户进行故障转移,而 100% 的组织则是理想的选择。

灾难恢复

优点和缺点

优点:

  • 由于平台“始终开启”,因此恢复时间短
  • 支持存储和依赖网络的组件,例如 NetScaler、MCS、PVS
  • 最小恢复计划(DR 编排)文档
  • 对最终用户无缝衔接
  • 支持使用 GSLB 在 Citrix Gateway 上进行的 EPA 扫描(从 2022 年起发布的 NetScaler 13.0+ 固件版本可以容纳 Active-Active GSLB 配置下的 EPA 扫描,以前只能在主动-被动配置中运行)

缺点:

  • 由于灾难恢复中的“热”硬件处于待机状态和 NetScaler 许可,因此成本更高。如果将备用容量用于开发或其他不太重要的非生产工作负载(可以在灾难恢复期间关闭电源以确定生产恢复的优先级),则可以在一定程度上减轻成本负担
  • 最高的访问层复杂性
  • 使备用平台的配置和更新与生产同步所需的管理开销更高
  • 依靠管理员监视和调整所有数据中心的资源和硬件容量,以确保随着平台的发展,灾难恢复容量的完整性不会受到影响

使用案例和假设

企业组织中更高级但更常见的配置,它允许访问层 URL 通过 NetScaler GSLB(需要 NetScaler 高级或更高版本)以“主动-主动”方式运行。此功能在本地数据中心彼此靠近的环境中,或者在数据中心可以远程但可以将用户固定到首选数据中心(通常由高级 StoreFront 配置和 GSLB 驱动)的情况下非常有用,以满足多站点场景的需求。

此模型假设一个成熟的 IT 组织以及足够的 WAN 和计算基础架构来支持故障转移。此模型还假设应用程序和用户数据依赖关系与最新的站点版本/更新保持一致,并且可以以类似的自动化方式在灾难恢复设施中恢复,以减少对最终用户的长期服务造成的影响以及由于部分解决方案功能而造

公共云中的灾难恢复

涉及预备到云平台或云到云的灾难恢复自身带来了一系列挑战或注意事项,这些挑战或注意事项通常不会出现在本地恢复方案中。

在灾难恢复设计规划期间,可以考虑以下关键注意事项,以避免可能导致应用云基础架构的灾难恢复计划失效、成本过高或在灾难恢复时无法满足目标容量的失误

考虑因素 — 网络吞吐量

影响领域

可用性 性能 成本

详细信息

组织可能会低估其云解决方案中的吞吐量交汇点,包括虚拟防火墙、VPN网关和广域网上行链路(AWS Direct Connect、Azure Express Route、GCP云互连等),如果Citrix平台要在云中恢复并可通过广域网进行访问,这些连接点可能会对性能产生重大的有害影响。另外,如果与云提供商一起使用,请注意VPN网关的限制。例如,AWS Transit Gateways 目前的最大限制为 1.25 Gbps。此限制可能需要扩展网关,或者可能需要使用多个 VPC(如果这些对云架构至关重要)。Azure 和 GCP VPN 网关将有更高的限制。许多虚拟防火墙对可以处理的吞吐量或最大吞吐量都有许可限制,即使达到最高限制。此限制可能需要扩大防火墙的数量并以某种方式对其进行负载平衡。

建议

在建立吞吐量大小计算时,假设已满的灾难恢复容量负载。捕获每个并发用户的以下数据:

  • 估计 ICA 会话带宽
  • 如果应用程序跨越安全边界,则每个会话的估计通信带宽
  • 如果文件服务超越安全边界,则每个会话的估计带宽

对于之前的指标,收集有关生产中 VDA 的当前流量模式的数据可能很有用。同样重要的是要考虑与 Citrix 无关的其他数据流也会使用这些网络路径。在规划 Citrix DR 时,一定要让网络和安全团队参与进来,以确保所有跨越安全区域和网段的带宽估计值都得到理解和满足。

注意事项-身份验证服务

影响领域

可用性 性能 安全性

详细信息

身份验证服务对于 Citrix 平台的运行至关重要。大多数人继续依赖 Microsoft Active Directory 域服务 (AD DS)。如果使用 Citrix 联合身份验证服务 (FAS),Microsoft 证书颁发机构 (CA) 或支持的第三方 CA 对于平台的持续运行也至关重要。也就是说,如果他们关闭,Citrix 就会关闭。

一些组织继续拒绝在公共云中部署身份验证服务基础架构,这通常是出于安全考虑。因此,在正常运行期间回溯到可写的本地域控制器 (DC) 时,身份验证和代理性能会受到阻碍,灾难恢复场景中 DC 和 CA 的可用性和可访问性不容忽视。

建议

实施足够的补偿控制措施来解决安全团队的担忧,并将 可写 的 DC 和 CA(如果使用 FAS)放置在云端的 Citrix 基础架构附近。如果无法商量,请确保在生产数据中心出现故障或无法访问时对这些服务器进行恢复计划并验证这些服务器的可访问性。

考虑因素 — Windows 桌面操作系统授权

影响领域

成本

详细信息

对于在不同云平台上运行的 Microsoft 桌面操作系统实例,可能存在复杂的许可注意事项。Microsoft 于 2019 年 8 月 修订了其云许可权 ,这可能会影响 VDI 在某些部署方案中的成本影响。Microsoft 对 Office 365/Microsoft 365 应用程序的许可在公共云和操作系统类型的支持方面也是一个不断变化的格局。

建议

Microsoft 产品的许可是一个不断演变的问题。在确定用例架构时,有关许可和支持性声明的最新详细信息,请参阅 Microsoft 和云提供商(如果相关)。如果灾难恢复解决方案中的 VDI 存在潜在的成本挑战,请考虑在可行的情况下补充托管共享桌面(可能需要增强 RDS CAL),因为它们可以以更 低的运营成本提供更大的灵活性。限制或未来的支持变更需要完全重新评估用于灾难恢复的平台。

考虑 — VDA 向外扩展的时间(DR 之前或期间)

影响领域

成本 可用性

详细信息

只有在需要时才为容量付费的吸引力吸引了组织使用云端。此解决方案可以通过不为预留的基础架构付费而大幅降低灾难恢复成本,无论是否使用

但是,在大规模情况下,云提供商不能承诺同时开启数百或数千台虚拟机的 SLA。如果预计灾难恢复的 VDA 占用空间将达到数百或数千个实例,则此解决方案将变得特别具有挑战性。云提供商倾向于为手头的各种实例大小保留批量容量;但是,该提供商可能因时而异。如果发生影响某一地理区域的灾难,其他租户也可能会提出按需容量的强烈争论。

对于 Azure,不要将预留实例与预留(按需)容量混淆。如果选择预留实例作为灾难恢复区域资源可用性的对冲工具,则应谨慎行事,因为 Microsoft 不保证容量按需可用。对于按需容量,Microsoft 会直接预留容量(按即用即付费率)。归根结底,可以谨慎地假设只有运行的 VDA 才能保证可用。

需要回答的可能影响决策的关键问题:

  • 是否始终需要 100% 的 DR 容量?
  • 计划应对哪些类型的灾难?如果是区域性灾难,那么使用单个云区域还是靠近生产的云区域是否明智?
  • 我们是否只托管关键工作负载(也就是说,仅托管生产的子集)?
  • 灾难恢复时向外扩展是可行的吗?如果是这样,DR 级别是否对使用案例进行了优先级,以便更好地了解每个使用案例的不同 RTO 以支持分阶段缩减容量?
  • 我们能否扩大支持应用程序或托管共享桌面用例的操作系统实例,以节省预置时间并关闭这些实例的电源以节省运营成本?

建议

Citrix 建议首先与您的云提供商联系,以确定在 RTO 时间范围内开启预期容量的可行性,以及按需实例能否满足此要求。为了避免灾难恢复方案中 VDA 的容量可用性限制,Citrix 建议在尽可能多的可用区域内 Provisioning VDA。

在大规模上,可能值得跨不同云区域进行配置,并相应地调整架构。一些云提供商建议使用不同大小的 VM 实例类型,以进一步减少 VM 耗尽。

一些组织希望分散供应商风险,采用多云部署,在两个不同的云提供商之间配置用例,以对冲整个云平台的故障(DNS、路由、漏洞等)。
这种情景确实增加了复杂性,并且在云之间性能或功能不相上下,但是平台多元化的感知价值使这些潜在的小警告黯然失色。 在可能的情况下,谨慎的做法是预先配置 VDA 实例并定期对其进行更新(保持在线或离线状态将由客户自行决定,风险承受能力由客户自行决定)。配置是一个资源密集型和时间密集型过程,通过预置可以在一定程度上加快按需扩展 VDA 灾难恢复容量。

如果组织对容量可用性风险的兴趣不大,则可能需要应用预留或专用计算容量并相应地进行预算编制以保证资源可用性。通过引用灾难恢复层,可以将按需模式和预留/专用模式结合起来,其中某些用例可能要求 VDA 立即可用,而其他用例可以灵活地在几天或几周的更长 RTO 内恢复,如果它们对维持业务不那么重要。

考虑 — 应用程序和用户数据

影响领域

成本 可用性 表现

详细信息

用户数据和应用程序后端的位置可能会对 Citrix DR 环境的性能产生显著影响,有时还会对可用性产生显著影响。某些客户场景使用多数据中心灾难恢复方法,在这种方法中,并非所有应用程序后端或用户数据(例如家庭和部门驱动器)都无法与 Citrix 一起恢复到云中。这种差距可能会导致意外的延迟,从而影响应用程序的性能甚至功能。从吞吐量的角度来看,这种差距可能会进一步增加可用网络和安全设备带宽的压力。

建议

在可能的情况下,将应用程序和用户数据保持在 DR 中的 Citrix 平台本地,以便通过减少 WAN 中的延迟和带宽需求,尽可能保持最佳性能。确定灾难恢复中实际需要恢复的内容(FSLOGIX Office Containers可能并不重要,有些用例在创建新的配置文件后可以正常工作),并确保灾难恢复站点中提供应用程序包和容器。确定最合适、最经济高效的复制解决方案至关重要。本 指南稍后将进一步讨论这个话题。

Citrix Cloud 的灾难恢复规划

在灾难恢复规划方面,Citrix Virtual Apps and Desktops 的本地部署或“传统”部署与 Citrix Cloud 提供的 Citrix DaaS 之间有几个显著的区别:

  • Citrix 为合作伙伴/客户管理大多数控制组件,从而免除了 Citrix 站点及其组件的重大灾难恢复要求。
  • 为 Citrix 资源部署灾难恢复环境只需要客户在恢复“资源位置”中部署 Citrix Cloud Connector,并可选择部署 StoreFront 和 NetScaler(适用于 Citrix Gateway)。
  • Citrix Cloud 独特的服务架构在地理位置上是冗余的,在设计上具有弹性。
  • 如果使用 Citrix Workspace 和 Citrix Gateway 服务,则不需要访问层 DR。

除了这些核心区别之外,以前各节的许多灾难恢复注意事项仍然需要合作伙伴/客户规划,因为如果未从 Citrix Cloud 使用 Citrix Gateway 服务和 Citrix Workspace 服务,他们仍将负责 Citrix VDA、用户数据、应用程序后端和 Citrix 访问层。

本节涵盖了帮助组织为 Citrix Cloud 定义适当的灾难恢复策略的关键主题。

Citrix DaaS 简化了灾难恢复

以下是典型的概念图,概述了 Citrix DaaS 的概念架构,以及对 Citrix 管理的组件和合作伙伴/客户管理的组件的责任分离。本文没有说明的是 WEM、Analytics 和 Citrix Gateway“服务”,它们是与 Citrix DaaS 相关的可选 Citrix Cloud 组件,属于“由 Citrix 管理”的范围。

灾难恢复

如图所示,需要恢复决策的控制组件中有很大一部分属于 Citrix 的管理范围。作为一项基于云的服务,Citrix DaaS 架构在 Citrix Cloud 区域内具有很高的弹性。它是 Citrix Cloud“Secret Sauce”的一部分,被考虑在 Citrix Cloud 的 SLA中。

服务可用性管理责任如下:

  • Citrix。控制平面并访问“服务”(如果正在使用)(Citrix Workspace、Citrix Gateway 服务)。
  • 客户。资源定位组件包括 Cloud Connector、VDA、应用程序后端、基础架构依赖项(AD、DNS 等)以及访问层(StoreFront、NetScaler)(如果不使用 Citrix Cloud 访问层)。

在 Citrix DaaS 上进行灾难恢复方面,组织可以获得以下优势:

  • 由于要管理的组件减少,以及在不同位置之间复制和维护的独立配置减少,因此减少了管理负担
  • 由于在云中集中配置“Citrix Site”,从而降低了 Citrix 部署之间出现人为错误和配置差异的可能性。
  • 简化了生产和灾难恢复部署的资源管理,因为要配置和维护的 Citrix 站点和组件减少,不同位置之间没有访问层管理(可选),以及 Citrix 资源的灾难恢复逻辑较少,因此简化了生产和灾难恢复部署的资源管
  • 通过集中化监视数据库,减少需要部署和维护的服务器组件,从而降低了运营成本,并获得跨部署环境趋势的单一视图。

Citrix DaaS 灾难恢复注意事项

尽管恢复计划的许多组件已从组织的管理范围中删除,但组织仍负责规划和管理位于资源位置内的组件的灾难恢复和高可用性(可选)。

我们如何解决可用性问题的最显著区别在于我们如何解释和配置资源位置。在 Citrix DaaS 本身中,资源位置以区域形式呈现。使用 区域首选项 ,我们可以根据我们指定的逻辑管理资源位置之间的故障转移。在传统部署的 Citrix Virtual Apps and Desktops 站点中使用区域首选项将被视为高可用性设计,但不是有效的灾难恢复设计。在 Citrix Cloud 上下文中,此选项是有效的灾难恢复解决方案。

前面讨论的大部分灾难恢复选项都适用于 Citrix DaaS,因此有许多选项可以满足组织恢复目标和预算。

在为 Citrix Cloud 的 Citrix DaaS 服务规划灾难恢复时,需要从基础设施规划的角度了解几个关键指导原则:

  • 资源位置。生产和灾难恢复位置在 Citrix Cloud 中设置为独立的资源位置。
  • Cloud Connector。每个资源位置必须至少部署两个Cloud Connector。为清楚起见,Cloud Connector 不是在灾难恢复事件期间必须手动或自动“恢复”的组件。它们必须被视为“热备用”组件,并且必须始终在每个位置保持在线状态。
  • 客户管理的访问控制器(可选)。出于多种原因,组织可以选择为 Citrix Gateway 和 StoreFront 服务器部署自己的 NetScaler,而不使用 Citrix Workspace 或 Citrix Gateway 服务。这些可能包括:
    • 定制身份验证流
    • 增强了品牌推广
    • 更大的 HDX 流量路由灵活性
    • 更深入地了解 HDX 网络性能 (HDX Insight)
    • 审核 ICA 连接和集成到 SIEM 平台
    • 在 Cloud Connector 与 Citrix Cloud 的连接被切断时,可以通过使用 StoreFront 的Cloud Connector的本地主机缓存功能继续运行

    与Cloud Connector一样,建议将 StoreFront 和 Citrix Gateway 组件作为“热备用”部署在恢复位置,而不要在灾难恢复事件期间恢复它们。

操作注意事项

维护 DR 平台对于保持其完整性至关重要,以避免在需要平台时出现不可预见的问题。关于操作和维护 DR Citrix 环境,建议遵循以下准则:

  • Citrix DR 平台不是非 Prod。拥有“待机”环境的组织可能会倾向于偷工减料,将灾难恢复视为测试平台。这种处理对解决方案的完整性产生负面影响。实际上,灾难恢复可能是最后一个推动变更的平台,以确保在维护发生灾难性错误时其效用不会受到影响,这种错误在非生产环境中是没有表现出来的。
  • 修补和维护。使用“热备用”Citrix 平台时,与生产同步进行日常维护对于维护灾难恢复平台的正常运行至关重要。在操作系统、Citrix 产品和应用程序补丁方面,保持灾难恢复与生产同步非常重要。为了降低风险,建议在修补生产和修补 DR 之间留出几天到一周的时间。
  • 定期测试。无论灾难恢复涉及将生产复制到恢复设施还是使用“热备用”环境,都必须定期测试(理想情况下每年一两次)灾难恢复计划,以确保团队熟悉恢复流程,发现和修复平台或工作流程中的任何缺陷。实践造就完美。计划可以在纸上起作用,但测试表明,对RTO和RPO目标的预期无法实现,运营顺序需要调整或疏忽。例如,同步和故障转移存储的实际时间可能会导致意想不到的数据丢失,需要根据预期或复制配置进行调整。
  • 能力管理。对于主动-被动和主动“始终打开”Citrix 环境,灾难恢复也必须考虑生产中的容量或用例更改。特别是在使用 Active-Active 模型时,资源利用率很容易提高到超过每个环境中资源的 50% 稳定状态利用率阈值,仅适用于发生灾难恢复事件和幸存平台变得不堪重负并且性能不佳或由于超载。容量可以每月或每季度进行审查。

数据恢复注意事项

在本节中,我们将简要介绍与在多位置和灾难恢复场景中处理用户配置文件、VDA 映像和应用程序(App-V、App Layers、MSIX 等)相关的几个概念和注意事项。

复制与备份

在考虑恢复关键数据集(例如核心基础架构、映像、用户数据和应用程序)时,数据可用性和完整性这两个功能都是重要的因素。虽然公有云解决方案中通常提供的复制功能提供了便捷的机制来确保关键数据的弹性,但复制并不能解决数据损坏或灾难恢复场景,即使是复制的数据也已被泄露。复制不能替代备份,在经济可行的情况下,必须同时使用两者。复制可以帮助快速恢复数据,而备份可以帮助从数据丢失或损坏中恢复(在保留策略和备份间隔规定的范围内)。无论是在本地还是在云端,都有多种备份选项可供选择。

在谈到这个话题时,在当前的网络安全形势下,谨慎地考虑备份保留政策是谨慎的,因为勒索软件攻击现在采用“定时轰炸”,在这种攻击中,数据集遭到入侵,但看起来很正常,而勒索软件在特定日期之前仍处于休眠状态。通过玩“漫长的游戏”,网络犯罪分子可以使保留期较短的备份在恢复后毫无用处。延长保留期会增加成本,但会提高恢复关键数据的概率。

我该恢复什么?对数据重要性进行分类

尽管本文的大部分内容都侧重于 Citrix 基础架构的可用性和恢复选项,但也考虑了各种数据集的可用性,以使业务预期与成本保持一致。例如,如果灾难恢复位置的用户配置文件不可用,这只会给业务运营带来不便还是重大障碍?这个问题的答案将直接影响基础架构组件的复杂性和成本。以下是与 Citrix 平台相关的常见数据注意事项清单:

  • 用户个人资料。包括 Citrix Profile Management (CPM) 配置文件或容器、用户层或 FSLogix 容器。组织必须确定是否必须在灾难恢复中对其进行恢复,以及它们的 RTO 和 RPO。对于某些用例,如果在灾难恢复中设置新配置文件会增加用户负担 10-15 分钟,则在灾难恢复中恢复配置文件的成本不值得对于其他用例,这是不可谈判的。办公容器不值得复制,因为它们是在线数据的缓存。用户配置文件/用户数据讨论中的这种差异允许通过选择不复制这些容器(并有理由将FSLOGIX配置文件容器与Office容器分开)来降低存储和复制成本。
  • 映像/层。在大多数情况下,对于是否恢复映像(主映像、PVS vDisk、App Layering 层),除了如何恢复映像之外,并不需要做出真正的决定。它们会自动复制吗?还是它们是在生产和灾难恢复之间独立维护?
  • 应用程序。这里我们特别指的是容器化应用程序(弹性层、MSIX、App-V)。与映像一样,决定往往更多地取决于我们的“如何”恢复,而不是“如果”。

复制选项

无论是在公共云中还是在本地,都有多种复制技术可供选择。本节涵盖了许多常见选项,但并不详尽。请注意,在许多使用复制的场景中,除非灾难恢复位置允许同步复制,否则一定程度的数据丢失是不可避免的。否则,恢复选项通常会考虑 RPO,通常最低为 15 分钟(取决于平台/工具/场景)。复制间隔越频繁,成本通常就越高。

对于许多组织来说,(所有形式)的用户配置文件、用户层、应用程序和映像可能能够承受一天的数据丢失,从而减少跨站点流量和带宽消耗。在某些用例中,在灾难恢复和复制成本的背景下,用户资料数据丢失对业务无关紧要。无论选择哪种选项,IT 和业务部门都必须意识到在计划外灾难恢复事件期间可能丢失数据方面的预期。计划中的灾难恢复活动使您有机会在故障转移之前完成数据的完整复制。

在公有云中,诸如 Azure NetApp 文件、Azure 文件和 AWS FSx 之类的本机文件服务解决方案在存储用户数据方面很常见,并且通常具有在区域内或其他区域的内置复制功能。如果在云平台内规划生产和灾难恢复并将数据复制到其他区域,请在选择区域时注意其区域对是什么,以确保数据可以复制到您想要的区域。Azure 在此处维护跨复制区域对的列表。Azure NetApp Files 在此处也有自己的跨复制区域对列表。如果在 Azure 中未配对的区域进行部署,则数据可以恢复到会给 VDA 带来更多延迟的区域。

在某些情况下,可以通过不依赖此类技术并使用应用程序级复制功能(例如 FSLogix(如果使用)Cloud Cache来克服这个问题。相比之下,AWS FSx 不限制通过区域对进行复制,从而提供了更多选择。请注意不会保留 SMB 连接的云复制选项。例如,如果使用地理冗余存储 (GRS),Azure 将无法维护 SMB 帐户或租约,这可能会根据故障情况影响用户,并且需要注销/登录才能重新安装受应用程序、层或配置文件影响的共享。

第三方选项,尤其是 NetApp Cloud Volumes onTap (CVO),也可在主要的公有云(包括 GCP)上使用,深受熟悉 NetApp 且希望在云中获得类似管理和功能体验的组织的欢迎。

与 Azure GRS 示例一样,请注意,许多涉及数据中心或公有云区域之间文件共享恢复的技术都不会保留 SMB 连接。对于无法自动重试访问且还需要手动恢复共享/卷的技术,这可能导致用户需要在故障转移时注销并登录以重新安装文件共享。在用户登录不同于生产的 VDA 以恢复工作效率的完整灾难恢复场景中,这种情况并不明显。

长期以来,Citrix Professional Services 一直建议组织在本地使用本机文件管理器平台(即 SAN 或 NAS 设备提供的 IP 网络文件服务),这是基于其强大的功能集以及与基于 Windows 的文件服务器解决方案相比更低的开销。在为灾难恢复站点规划存储复制功能时,这一点尤其重要。

如果硬件/设备文件管理器解决方案不可用,则基于 Windows 的解决方案是后备方案(请务必 按照 Microsoft 的指导进行调整 并进行适当备份),有多种选项可供选择,但其性能和容量可扩展性可能比内置解决方案更受限制:

  • 独立文件服务器。用于托管 Citrix 数据需求的基本 Windows 文件服务器,包括配置文件和应用程序容器、用户配置文件、Microsoft 文件夹重定向等,前提是环境不是全天候运行且可以承受中断。
    • 优点: 易于设置和维护
    • 缺点:没有高可用性,没有复制能力,除非在其他技术(如 DFS-R、存储副本或 VMware Site Recovery Manager (SRM)、Veeam、robocopy 等)上进行分层,否则重启(计划内或计划外)会中断用户配置文件、用户数据(例如主硬盘和 Microsoft 文件夹重定向)、已安装的应用包、个人虚拟磁盘访问(可能导致 PVS 目标崩溃)
  • Windows 文件群集。这是一项 Windows 环境中的支柱技术,依赖于 Windows 故障转移群集。旨在为本地数据中心内的文件共享创建高可用性。
    • 优点: 强大而成熟的解决方案非常适合 Citrix 对各种配置文件和容器类型的数据需求,允许在节点之间进行故障转移,而不会中断客户端的 SMB 会话
    • 缺点: 不打算用作灾难恢复解决方案,而更多的是高可用性解决方案。根据所使用的共享存储架构,设置和维护可能会更加复杂,除非使用虚拟机级别的恢复协调工具(例如 VMware SRM)进行恢复,或者使用 DFS-R 甚至 robocopy 在两个群集之间复制更改,否则不适合跨数据中心
  • 分布式文件系统 (DFS)。DFS 复制 (DFS-R) 和 DFS 命名空间 (DFS-N) 是 Windows 中最古老的两个文件服务器复制和可用性选项,最初用于支持 Active Directory 复制功能。它们可以相互独立配置,但通常可以一起配置。它在长期存在的 Microsoft 组织中很普遍,这使其成为许多管理员熟悉的解决方案。但是,它对 Citrix 环境的支持适用性有限。
  • 优点: 管理员很熟悉,易于设置,可以跨越数据中心,不依赖复杂的群集配置(但可以分层到这些配置之上)
  • 缺点: DFS 有许多局限性,对于大多数 Citrix 相关的数据复制用例来说并不理想。对于各种常见的用户数据和配置文件场景,Microsoft 不支持 DFS-N 和 DFS-R 相互组合, 但在主动-被动(单向复制)场景中可以支持 DFS-N 和 DFS-R,手动故障转移(需要用户注销并重新登录才能重新建立文件服务器访问权限),不适用于托管应用程序包/容器,除非用户可以注销然后重新登录
  • 存储副本。存储副本 支持在多数据中心场景中在服务器或群集之间复制卷。它可以采用三种形式进行配置,包括延伸群集、群集到群集和服务器到服务器。异步复制和同步复制都是可能的。
    • 优点: 与 Storage Spaces Direct 一起使用以形成延伸群集时,支持自动故障转移。可能适用于用户配置文件、用户数据、配置文件容器、应用程序容器和层(取决于故障转移性能测试)。如果不使用拉伸群集,则可能仅适用于 FSLogix 容器
    • 缺点: 如果不使用 stretch 群集,则必须手动执行故障转移,这将切断需要注销/登录才能重新建立对用户配置文件和数据的访问权限的 SMB 会话。如果不使用拉伸群集,则不适合托管应用程序包/容器
  • 横向扩展文件服务器。横向扩展文件服务器 非常适合具有较大文件(例如虚拟机磁盘)或写入密集度不高的应用程序数据的用例。
    • 优点: SMB 持续可用性(减少节点间故障切换时的停机时间)非常适合 vHD、应用程序容器、层、配置文件容器,可以跨越数据中心
    • 缺点: 不建议基于 Microsoft 使用用户配置文件(漫游配置文件、CPM)、Microsoft 文件夹重定向

根据数据集的不同,在生产和灾难恢复数据中心之间保持相同的命名空间路径可能并不重要。为用户配置文件、应用程序包共享、弹性层或用户层、配置文件容器等保留独立路径可以降低复杂性。根据每个数据集类型评估影响,包括不在主动-主动场景中运行时反向复制和故障恢复的注意事项。在主动-主动场景中,将用户重新安置到一个区域数据中心而不是另一个区域数据中心将是理想的选择,这样可以避免在站点之间安装应用程序和数据容器并增加延迟。

App Layering 的恢复注意事项

对于运行 App Layering 的组织,请查看 Citrix 的 App Layering 参考架构,有几个组件适合备份,包括设备、弹性层共享和用户层共享。

  • 设备备份可确保即使设备以某种方式被销毁,所有层都可用。这些备份可确保即使设备以某种方式被破坏或损坏,所有层都可用。
  • 弹性层在登录时从 SMB 共享中挂载。通过使用适当的群集,确保用于弹性层的文件服务器/服务具有高可用性至关重要。使用支持中小型企业持续可用性的原生硬件(或云)文件共享解决方案或基于 Windows 的解决方案非常重要。对于此用例来说,使用多个 DFS-R 目标是不够的,因为如果目标失败,则在进行另一次登录之前,无法将已安装的 VHD 文件重新映射到另一个目标。同样,出于与前面讨论的类似原因,几种配置中的存储副本也不适合。
  • 从灾难恢复的角度来看,用户层更为复杂。这些可写入的 VHD 在登录时由 Windows 挂载,并由 Windows 桌面锁定。
    • 与弹性层一样,由于基于 Windows 的常用方法(例如 DFS-R 或 robocopy)的局限性,原生硬件或云文件共享解决方案是最佳选择。要知道,用户层往往更大,区块频繁更换,在块级别复制的复制方法要优于在更改时复制整个文件的复制方法,否则组织可能会看到站点间的用户层复制量难以维持。
    • 由于复制大型磁盘的困难或固有的成本影响,组织通常选择为没有复制用户层的用户提供灾难恢复桌面。

配置文件的恢复注意事项

无论配置文件位于本地数据中心还是公共云中,恢复配置文件都需要合适的存储复制和访问策略。本节旨在在先前讨论的针对每个配置的解决方案的恢复注意事项的基础上再接再厉。对于每个用例,一定要问“在灾难恢复场景中是否真的需要恢复配置文件?” 否则,成本和复杂性可能会大大降低。

一般建议:

  • 确认是必须复制配置文件数据,还是仅复制其中的一部分。例如,如果使用 FSLogix 配置文件容器,则可能需要将其拆分为配置文件和 Office 容器(如果依赖存储复制,则可能位于不同的共享空间上进行精细复制控制),以便灵活地复制配置文件容器,而不是 Office 容器(在灾难恢复期间可以按需创建)。
  • 首先在本地或云端使用专门构建的“原生”文件服务(文件管理器)平台。有许多 Windows 选项可用,但通常不那么强大(无论是在功能还是可扩展性方面),开销更大,还有更多注意事项。除了跨站点冗余之外,强烈建议使用本地冗余,以避免故障转移场景中可能中断 SMB 连接的一些常见陷阱。
  • 如果复制变化率较高的 VHD(往往是大文件),例如用户层和配置文件容器,请考虑复制解决方案,这些解决方案可以在块级别进行复制,并且不会在更改时触发文件的完整副本,否则存储提供商和网络吞吐量可能会不堪重负。
  • 考虑一下 RPO 间隔。时间越短,存储和网络系统的成本和负载就越高。平衡数据丢失容限和复制间隔的异步复制选项是最佳选择。
  • 设计解决方案,使配置文件位于任一位置 VDA 的本地配置文件以提高性能。
  • 如果使用 CPM 并计划使用 DFS,请参阅 CPM 灾难恢复文档了解 D FS 注意事项。
  • 根据测试,可以考虑使用 Cloud Cache 来简化复制和恢复,因为该功能可在应用程序级别处理配置文件数据的复制,并允许管理员根据每个数据中心(通常通过 GPO/OU 结构)设置容器目标共享的首选列表(每个文件服务器存储提供商一个)。云缓存的其他注意事项由 Microsoft 提供,在规划时必须参考。Cloud Cache 确实有缺点,某些情况可能会导致中断,因此鼓励组织审查潜在风险,以了解在应用程序级别处理配置文件复制和恢复的回报是否超过这些风险。
  • 规划故障恢复,这可能会导致从灾难恢复到生产环境的复制。

应用程序包的恢复注意事项

当我们提及应用程序包时,我们统称为 App-V、MSIX、弹性层和类似的应用程序包。它们通常是读取密集型的,但不是写密集型的,而且与配置文件相比,更新频率不高。以下是针对此数据类型的一些一般建议:

  • 首先在本地或云端使用专门构建的“原生”文件服务(文件管理器)平台。
  • 考虑为应用程序维护单独的文件共享(即不使用相同的路径或命名空间),并指定 VDA 使用其本地文件共享。手动或通过 robocopy 使文件共享保持同步。

映像恢复注意事项

灾难恢复策略中还必须考虑主映像和 PVS 虚拟磁盘。主映像如果丢失,则需要花费大量精力进行重建。App Layering 属于这个分类,但已经涵盖了。以下是一些需要考虑的一般性建议:

  • 如果在生产和灾难恢复之间依赖相同的映像,则在数据中心或云区域之间复制主映像和 PVS vDisk 考虑手动复制,以避免将损坏的映像推送到 DR 的可能性。
  • 将主映像和 PVS 虚拟磁盘(包括版本文件和清单文件)备份到异地位置而不是生产位置。
  • 如果使用 Azure,请使用 Azure 计算库(以前称为共享映像库)跨区域、订阅和租户复制映像,从而提供共享的映像存储库。

总结

我们已经在 Citrix 的灾难恢复主题上讲了相当多的内容。以下几点总结了本指南的核心消息和要点,供体系结构师和客户在规划其 Citrix 恢复策略时考虑:

  • 了解客户环境的业务需求和技术能力会影响 Citrix 所需的灾难恢复策略。所选择的恢复策略必须与业务目标保持一致。
  • 高可用性并不等同于灾难恢复。但是,灾难恢复可以包括高可用性。
  • 在物理位置之间共享管理边界并不能构成灾难恢复解决方案。
  • 为组织的技术产品组合开发灾难恢复分层分类可在制定恢复战略时提供可见性、灵活性和潜在的成本节约。
  • Citrix 基础架构和 Citrix 上托管的应用程序的 RTO 要求是定义灾难恢复设计的最重要影响因素。较短的 RTO 通常需要更高的解决方案成本。
  • 不采用“热”灾难恢复平台的 Citrix 灾难恢复架构限制了客户可以使用的技术,例如 Citrix MCS、NetScaler 和 Provisioning。
  • Citrix 的灾难恢复策略必须考虑用户数据和应用程序后端的恢复和恢复时间。Citrix 可以设计为快速恢复,但是,如果应用程序和数据依赖关系在相似的时间范围内不可用,用户仍可能无法工作。
  • 云环境中的灾难恢复有不同的考虑因素,在本地环境中不存在这些注意事项,组织必须对其进行审查,以避免在云环境中调用灾难恢复时出现不可预见的瓶颈或运营影响。
  • 必须保持灾难恢复组件的最新状态,以匹配生产更新和配置,以维护平台的完整性。
  • 在不同地点之间使用 Citrix 主动配置的平台必须注意容量监视,以确保在发生灾难时有足够的资源来支持一个或多个幸存地点的预计负载。
  • 组织必须定期测试其 Citrix 灾难恢复计划,以验证其运行情况和实现其核心目的的能力。
  • Citrix DaaS 显著简化了灾难恢复架构的许多方面,并允许通过区域首选项配置实现资源位置冗余。
  • 明智地为用户数据、应用程序包、图层、虚拟磁盘和配置文件容器规划和选择复制选项,以确保它们的局限性已为人所知,其功能与业务需求保持一致。
  • 不要将复制与备份混为一谈。由于勒索软件“定时轰炸”备份盛行,他们齐心协力,更深入地考虑备份保留率。

来源

本文的目标是帮助您规划自己的实施。为了简化此任务,我们想为您提供源图,您可以根据自己的需要进行调整:源图

设计决策:灾难恢复规划