Citrix虚拟应用程序和桌面——灾难恢复计划

概述

本指南帮助您进行业务连续性(BC)和灾难恢复(DR)体系结构规划以及Citrix虚拟应用程序和桌面的在本部署和云部署的注意事项。本博士身就范围广泛而言是一个重要的话题。Citrix承认本文档不是整体灾难恢复策略的全面指南。它并不考虑灾难恢复的所有方面，有时会从外行的术语角度看待各种灾难恢复概念。

本指南旨在解决对组织的 Citrix体系结构有重大影响的以下注意事项，并提供与之相关的体系结构指导：

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

业务要求

与 Citrix设计方法的 “业务层” 保持一致，收集明确的业务需求和服务恢复的已知限制。记录这些项目是为 Citrix制定任何恢复计划的起点。此步骤有助于澄清范围，并为最适合满足业务和功能要求以及限制因素的灾难恢复策略提供方向。

需要回答的有用问题包括但不限于以下内容。这些问题将在灾难恢复选项部分中根据它们如何影响思杰DR设计进行更详细的讨论：

• 备份策略和恢复时间目标 （RTO）今天服务器使用的备份策略是什么？备用频率？保留期限？异地存储？测试？的Citrix平台是否必须在发生灾难时立即可用或在特定时间段内联机？（请参阅灾难恢复层分类）。将的Citrix托管的应用程序连接到的应用程序后端包括在讨论中以调整期望是值得的。
• 恢复点目标(RPO)。对于RPO来说,哪种程度的数据丢失被认为是可以容忍的,这可能会因基础设施组件或数据分类而异?服务的恢复数据可以是多久吗?0 分钟?一个小时?一个月?在Citrix基础架构的上下文中,此考虑因素仅适用于数据库更改和用户数据(配置文件,文件夹重定向等)。与RTO一样,讨论中值得考虑Citrix托管应用程序的应用程序后端。
• 追回范围。此考虑因素不仅包括的Citrix基础架构，还可以包括的Citrix托管的应用程序客户端与之连接的用户数据或关键应用程序服务器。确定恢复的Citrix平台的时间与恢复的Citrix上托管的应用程序的时间之间是否存在差异非常重要。由于只有解决方案的一部分是在线的，所以三角洲可以延长停机。
• 使用案例。Citrix平台通常为众多使用案例提供服务，每个案例都具有不同的业务关键程度。恢复是否涵盖所有 Citrix使用案例?或者，企业的运营成功完全依赖的关键使用案例。答案对基础设施范围界定和容量预测有很大影响。如果 博士是 Citrix环境的净新功能，建议对用例进行细分和优先级处理，以便对 博士的启用进行分割。
• 能力。灾难恢复中是否有任何不能包含的关键功能可以降低成本?此功能的一个示例是使用永久桌面与非持久桌面；一些 VDI用例可由托管共享桌面，甚至特定的应用程序独奏提供服务。客户有时表示在 博士中不需要组件冗余（ADC）控制器、店面、SQL等）如果长期停产，这种决定可被视为风险。
• 现有博士其他的Citrix环境和其他基础结构服务是否存在现有的DR策略或计划？它是恢复到新的可路由子网中还是进入镜像生产网络的“泡沫”？答案有助于提供当前灾难恢复方法，工具或优先级的可见性。
• 技术能力。此考虑因素不能决定Citrix的最终恢复策略,但了解以下内容非常重要:
  • 恢复：组织内部提供哪些存储复制技术，虚拟机恢复技术（VMware的SRM，Veeam的，Zerfor，天青站点恢复（ASR）等）？的Citrix依赖项以及一些的Citrix组件可以使用它们。
  • Citrix：哪些 Citrix技术用于映像管理和访问?某些组成部分不能很好地适合某些复苏战略。由 MCS或 PVS管理的非持久性环境由于它们与存储和网络紧密集成，使虚拟机复制技术成为不佳的候选人。
• 数据严重程度。用户配置文件或用户数据是否被视为对恢复至关重要?持续的VDI吗?如果调时博士用此数据不可用,这是否会对生产力造成重大影响吗?或者是否可以将非持久性配置文件或VDI用作临时解决方案?此决定可能会增加成本和解决方案的复杂性。
• 灾害类型。此决定相当重要，但也可以通过公司 卑诗省或灾难恢复计划预先确定。此要求通常决定了恢复位置。该策略是否仅适应应用程序级别的服务恢复?五金机架之间?在一个地铁位置?在两个地区之间?两个国家?在云提供商区域或整个云提供商的基础设施（多区域）中?
• 客户端用户。在生产环境中访问服务的用户在哪里?此决定可能会对服务恢复到何处产生影响，包括公司网络连接，这可能需要在灾难恢复事件期间进行手动修改。此外，答案决定了访问层的注意事项。
• 网络带宽。每个用户会话平均消耗多少流量(ICA),应用程序,文件服务)?此决定既适用于云恢复,也适用于本地恢复。
• 回退（或故障回退）。在 博士情况得到解决后，组织是否已经有计划如何在生产中恢复服务?组织如何恢复到正常状态?灾难恢复中可以创建的新数据如何与生产协调和整合?

博士约束限制了BC /设计选项或其配置。它们有多种形式，但可能包括：

• 监管或公司政策。此决策可以决定哪些技术可以或不能用于复制或恢复、如何使用这些技术、RTO或设施之间的最小距离。
• 基础设施。是否有关于要使用的硬件类型、可用网络带宽等的指令?这些考虑可能会影响RPO考虑因素,甚至可能带来风险。例如，灾难恢复中规模不足的防火墙或网络管道最终可能导致中断，因为网络依赖关系无法处理灾难恢复工作负载。或者，在计算的情况下，虚拟机管理程序主机不足或使用不同的虚拟机管理程序完全可能会影响选项。关于网络,如果恢复站点在为广域网提供服务时的网络吞吐量能力相对于生产能力的限制更大。在云环境中,尤其是在扩展到数千个席位时,由于组件服务的限制,例如虚拟防火墙,VPN网关和云到广域网上行链路(AWS直接连接,Azure ExpressRoute谷歌云互连等),这种潜在风险可能很快成为重大瓶颈)。
• 预算。DR解决方案带来的成本可能与项目预算冲突。通常情况下，RTO越短，成本就越高。
• 地理学。如果已确定指定的灾难恢复设施，则必须了解从生产到灾难恢复设施的延迟以及用户连接到灾难恢复等考虑因素。
• 数据驻留或数据分类。此决定可能会限制区域设置、技术或恢复方法方面的选项。
• 云恢复。是否需要在云中恢复基础设施而不是在本地设施中恢复基础设施?
• 应用准备状态。Citrix上托管的具有后端依赖关系的应用程序是否有 BC/DR计划?RTO的阵容如何达到 Citrix的目标 RTO？Citrix可以用于快速恢复，但是如果核心应用程序没有恢复计划或具有扩展 RTO的恢复计划，则此风险可能会影响 博士
• 网络安全。组织是否有可能规定哪些流量段在传输过程中需要加密的安全策略？这个考虑因素是否因所遍历的网络链路而有所不同？答案可能需要在灾难恢复方案中使用SSL VDA，ICA代理，GRE或的IPsec VPN封装ICA流量，如果灾难恢复的网络流量不同于生产流量。

对灾难恢复 （博士）设计的误解

本文通篇提到的 Citrix博士设计最常见的误解之一是，跨越两个数据中心的单个控制平面构成 博士它没有。跨越数据中心的单个 Citrix站点或 PVS场构成了高可用性设计，但不是灾难恢复设计。有些客户选择此路径作为一种业务决策，评价基于 博士功能的简化管理。店面服务器组仅在连接良好（低延迟）的数据中心之间支持。同样，还记录了在跨数据中心部署时需要考虑的最大延迟，如CTX220651中所述。

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

除了上述HA概念参考之外,应用区域的HA体系结构还适用于希望提供跨地域冗余但不要求平台完全恢复的客户。传统IMA体系结构(XenApp 6.5及更低版本)的区域概念经过重新设计,并在XenDesktop 7.7中重新引入,在7.11中进行了重大增强,允许各种站点内冗余功能,可以解决多位置部署的挑战。

在使用区域偏好（7.11 及更高版本）功能的站点体系结构中，相同的 Citrix资源将跨多个区域部署并聚合到单个交付组中。可以根据应用程序、用户的主区域或用户位置来控制区域首选项（能够回退到给定资源的其他区域）。有关此主题的更多信息，请参阅区偏好内部(区域偏好时间间隔)。VDA注册自动更新功能(在XenDesktop 7.6中引入)允许VDA维护站点中所有控制器的本地缓存的最新列的表。此功能允许卫星区域内的共识在本地区域不可用时将其本地交付控制器或云连接器的注册故障切换到主区域。店面服务器组位于每个区域位置中,建议用户在主区域不可用的情况下继续从本地访问层访问资源。

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

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

与Citrix托管的应用程序和桌面接口的文件服务(用户数据和共享上的业务数据等)和应用程序后端的恢复注意事项类似重要,有时客户没有充分考虑。引用早期应用程序准备情况时,Citrix博士平台可设计为在短时间内恢复。但是,如果这些核心使用案例依赖关系不具有与Citrix相似的RTO的恢复计划或根本没有恢复计划,则此计划可能会影响Citrix如预期的那样在灾难恢复中成功故障切断,但用户无法执行其工作功能,因为这些依赖关系仍然不可用。例如,在Citrix上托管其核心EMR应用程序的医院。发生灾难恢复事件,Citrix会故障切换到灾难恢复中的“始终在线”Citrix平台,用户正在连接,但EMR应用程序通过更多手动方式恢复,可能需要数小时或数天才能完成。在此期间，临床工作人员可能会被迫使用离线流程（笔和纸）。这样的结果不能与企业对恢复时间或用户体验的总体预期相一致。

下一节将讨论DR与更详细的医管局。

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

了解HA与灾后恢复对于满足组织需求和实现恢复目标至关重要.HA不是DR的代名词，但DR可以使用HA本指南对医管局和医管局的解释如下：

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

虽然HA倾向于嵌入设计规范和解决方案部署,但主博士要关注人员和基础设施资源的协调规划,以调用服务恢复。

医管局可以包括医管局吗?是。对于企业任务关键型 信息技术服务，这种概念很常见。例如，以上 哈描述中的第二个示例以及与解决方案相关的其他非 Citrix组件的适当恢复将被视为高度可用的 博士解决方案，其中服务 （Citrix）故障转移到对方数据中心。该特定体系结构可以在各种多站点迭代中实现为主动-被动或主动-主动，例如适用于所有用户的主动-被动、用户偏好一个数据中心而不是另一个数据中心的主动-主动，或者在不偏好的情况下在两个数据中心之间进行负载平衡的主动-主动。必须注意的是，在设计此类解决方案时，必须持续考虑、考虑备用容量并持续监控负载，以确保在需要时仍有容量来容纳灾难恢复。

还必须使灾难恢复组件与生产保持最新，以保持解决方案的完整性。客户常常忽略此活动，他们以良好的意愿设计和部署此类解决方案，然后开始在生产中消耗更多平台资源，忘记增加可用容量以保持解决方案的灾难恢复完整性。

在 Citrix上下文中，根据已发布指南，对于某些组件（例如店面服务器组），在两个数据中心（如两个地理本地化设施）之间跨越的Citrix管理域（的Citrix网站，PVS场等）不构成灾难恢复。同样，根据已发布指南，由于 PVS的数据库延迟限制，此类部署也可能不受支持。根据已发布指南，由于卫星控制器和数据库之间的最大延迟，地理位置之间的可支持性限制有时也延伸到思杰网站和区设计。

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

灾难恢复层分类

博士的层分类是组织 博士策略的一个重要方面，因为它可以清楚地说明应用程序或服务关键程度，而这又决定了 RTO(从而导致完成该恢复级别的成本）。通常，RTO越短，灾难恢复解决方案的成本就越高。能够将各种相互依赖关系分解为不同的分类（基于业务关键性和 （RTO）有助于优化成本敏感的 博士案例。

以下是一组示例 博士层分类，用于在评估 Citrix上托管的 Citrix基础结构服务、其依赖关系以及关键应用程序或使用案例（并与 VDA关联）时作为参考。博士层按顺序或恢复优先级进行概述，其中 0是最关键的。鼓励组织应用或开发与自己的恢复目标和分类需求保持一致的灾难恢复分层分类。

灾难恢复层 0

层 0-恢复目标（示例）

恢复时间目标：0

恢复点目标：0

0级 - 分类示例

核心IT基础设施

• 网络和安全基础设施
• 网络链接
• 虚拟机管理程序和依赖关系（计算、存储）

核心它服务

• 活动目录
• DNS.
• DHCP
• 文件服务
• 无线电数据系统许可证
• 关键最终用户服务 （Citrix）

级别 0-备注

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

灾难恢复级别 1

级别 1-恢复目标（示例）

恢复时间目标：4.小时

恢复点目标：15分钟

第 1.级-分类示例

关键应用程序

• 网站和 网状物应用程序
• 企业资源计划和 客户关系管理应用程序
• 业务线应用程序

Citrix使用案例

• 管理
• 客户服务或销售
• 信息技术工程与支持

第 1 级-备注

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

灾难恢复级别 2

第 2 层-恢复目标（示例）

恢复时间目标：48小时

恢复点目标：1.小时

第 2 级-分类示例

非关键应用程序非关键Citrix使用案例不影响第1层或第0层应用程序的功能的用户数据。

第2级 - 备注

对业务运营至关重要但短期无法使用的应用程序或使用案例不太可能造成严重的财务、声誉或运营影响。这些应用程序可以从备份中恢复，也可以通过自动恢复工具作为最低优先级进行恢复。

灾难恢复级别 3

级别 3-恢复目标（示例）

恢复时间目标：5.天

恢复点目标：8 小时

第 3 级-分类示例

不常使用的应用程序

第 3.级-备注

中断影响可以忽略不计的应用程序在一周之内无法使用。 这些应用程序可能会从备份中恢复。

灾难恢复级别 4

第 4 级-恢复目标（示例）

恢复时间目标：30 天

恢复点目标：24 小时或无

第 4 级-分类示例

非生产环境

第 4.级-备注

应用程序,基础架构和VDI中断对业务运营的影响可以忽略不计,可以在较长的时间内恢复。他们也可以有延长的RPO,或者根本没有这取决于他们的性质。这些RPO可以从备份中恢复,也可以在灾难恢复中构建全新的RPO,被视为要恢复的最后一层。

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

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

• Citrix基础结构对于业务运营的重要性有多大?重要的是要考虑，如果 Citrix被视为重要，但其托管的应用程序被视为关键，则 Citrix基础架构将被归类为关键。
• Citrix托管的使用案例或核心业务应用程序,它们是否具有不同的博士层分类?

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

第二个问题强调了 Citrix使用案例的分类，并在云环境中稍后更详细地讨论了最为重要。在云中,适应“始终在线”的应用程序或桌面平台与被认为不太关键业务的应用程序或桌面之间,存在着重大的成本考虑因素。这些考虑因素还会影响生产中的应用程序或使用案例隔离（孤岛），以利用灾难恢复平台中的部署灵活性。

为 Citrix建立灾难恢复设计时，将讨论超出 Citrix本身的范围对于设置业务部门的期望非常有用。例如，Citrix环境被视为 “始终打开” 服务，并且在备用数据中心中具有高可用性，但 Citrix托管应用程序所依赖的关键应用程序后端在调用恢复时将在几个小时内保持不可用状态。这种差距造成了两个平台之间的恢复时间差异，并可能在恢复过程中提供误导性的用户体验。Citrix立即可用，但关键应用程序无法正常运行。从一开始就设定预期可以让所有利益相关者适当了解恢复体验的样子。在某些情况下，客户可能希望将 Citrix保持在对立设施中的热备用状态（始终打开），但手动控制访问层的故障转移，以避免对平台可用性产生误解。

灾难恢复选项

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

将之前的几个灾难恢复问题关联起来，以下问题主题具有 Citrix博士设计含义，如下所示：

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

以下列表概述了的Citrix的各种常见恢复选项。现场存在每种调整，但是为了比较起见，我们概述了每种基本版本。这些选项从最简单（通常更高的RTO和更低的成本）开始，通过更高级的RTO（通常较低的RTO但成本更高）。对于给定组织来说，理想的选择是，除了可用的IT技能，预算和基础架构之外，还与托管应用程序或使用案例的恢复时间保持一致。此外，尽管可以实现，但许多选项表明，与网络和存储集成的的Citrix技术（如ADC和单映像管理技术）不适合“始终开启”恢复模式以外的其他方法这并不是。说从技术上讲是不可能实现的，但实现这些目标所涉及的复杂程度会使恢复风险更大，而且更容易出现人为错误。

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

优点和缺点

优点：

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

缺点：

• 高停机时间影响
• 更大，更详细的恢复计划（DR编排）文档
• 延长恢复时间
• 依赖于备份的完整性和期限
• 如果需要手动重新配置（网络等），人为错误的程度更高
• 不适合MCS或pv
• 由于网络连接，不适合 Citrix VPX模数转换器(并且必须应用nsconfig目录和ns.conf文件备份重建）

使用案例和假设

对于不太成熟的 信息技术组织和 信息技术运营预算有限的组织非常有用，并且可以允许延长中断以恢复核心业务服务。假定定期对备份进行恢复完整性测试，并遵循明确记录的恢复过程。

恢复选项-通过复制恢复

优点和缺点

优点：

• 复制可能是自动化的,并与RTO和RPO对齐
• 与自动恢复解决方案相比，可能使用不太复杂的技术

缺点：

• 依靠行政干预
• 更大，更详细的恢复计划（DR编排）文档
• 如果需要手动重新配置（网络等），人为错误的程度更高
• 不适合MCS或pv。计算机目录的复制已纳入预计的RTO中。但是,通过在中博士创建虚拟计算机目录或博士在中扩展VDA实例,然后执行应用复制的主映像的“更新目录”操作,可以缩短此RTO
• 由于网络连接，不适合思杰VPX ADC，因此更适合使用热备用ADC

使用案例和假设

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

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

优点和缺点

优点：

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

缺点：

• 依靠VMware的SRM，Veeam的，Zerin，ASR等更先进的技术来协调恢复和修改网络参数
• 不适合MCS或pv。计算机目录的复制必须纳入预计的RTO。但是,通过在中博士创建虚拟计算机目录或博士在中扩展VDA实例,然后执行应用复制的主映像的“更新目录”操作,可以缩短此RTO
• 由于网络连接，不适合思杰VPX ADC，因此更适合使用热备用ADC

使用案例和假设

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

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

优点和缺点

优点：

• 由于平台”始终打开”,恢复时间短
• 支持存储和网络相关组件，如 VPX、MCS、PVS
• 更低的恢复计划（DR协调）文档

缺点：

• 依靠管理干预来故障转移URL或引导用户到备份URL
• 由于 博士中的“热”硬件处于待机状态，成本更高
• 更高的管理开销，保持备用平台的配置和更新与生产同步

使用案例和假设

对于具有适当资源和 博士设施预算的企业组织非常有用。可以使用热备用 “完全扩展” 平台或 “按需扩展” 平台。后者可能会通过注意事项吸引云恢复以降低运营成本。

在故障转移时，管理员将一个或多个访问URL的**域名系统* *条目更新为指向Citrix网关和店面的一个或多个IP博士或者通过正式通信建议用户开始使用“备份”或“博士”的URL。

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

此模型假定这组织成熟,并且有足够的WAN和计算基础架构可用来支持故障转移。

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

优点和缺点

优点：

• 由于平台”始终打开”,恢复时间短
• 支持存储和网络相关组件，如 VPX、MCS、PVS
• 最小恢复计划（DR编排）文档
• 由于 统一资源定位地址故障转移，最终用户更容易
• 支持 Citrix网关的 美国环保署扫描

缺点：

• 由于 博士中的“热”硬件处于待机状态并且 Citrix ADC许可，成本较高
• 更高的访问层复杂性
• 更高的管理开销，保持备用平台的配置和更新与生产同步

使用案例和假设

与企业客户通用配置，允许通过 Citrix ADC GSLB(需要 模数转换器高级或更高级）自动故障转移到 博士站点。 此模型假定 信息技术组织成熟，广域网足够，并计算基础架构来支持故障转移。此模型还假定应用程序和用户数据依赖关系与最新的 忙碌的站点版本/更新保持一致，并且可以类似的自动化方式在灾难恢复设施中恢复，以减少对最终用户的长期服务和由于部分解决方案功能造成的混乱。

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

优点和缺点

优点：

• 由于平台”始终打开”,恢复时间短
• 支持存储和网络相关组件，如 VPX、MCS、PVS
• 最小恢复计划（DR编排）文档
• 无缝连接到最终用户

缺点：

• 由于 博士中的“热”硬件处于待机状态并且 Citrix ADC许可，成本较高
• 最高的访问层复杂度
• 更高的管理开销，保持备用平台的配置和更新与生产同步
• 主动/主动 GSLB目前不支持 Citrix网关上的 美国环保署扫描，建议用于 Citrix网关URL的主动/主动 GSLB配置
• 依靠管理员监视和调整所有数据中心的资源和硬件容量，以确保随着平台的增长，博士容量完整性不受影响

使用案例和假设

更高级但常见的企业客户配置，允许访问层 统一资源定位地址通过 Citrix ADC GSLB(需要 模数转换器高级或更高级）以主动-主动方式运行。此功能在本地数据中心彼此靠近的环境中，或者在数据中心可以远程但可以将用户固定到首选数据中心（通常由高级 店面配置和 GSLB驱动）的情况下非常有用，以满足多站点场景的需求。

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

公共云中的灾难恢复

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

灾难恢复设计规划过程中可以解决以下关键注意事项，以避免出现错误，这些错误会导致应用云基础架构的灾难恢复计划无效、成本过高，或者在 博士发生时无法满足目标容量

考虑因素 - 网络吞吐量

影响领域

可用 性能 成本

详细信息

如果 Citrix平台要在云中恢复并可通过万。 Azure VPN网关和 自动气象站传输网关目前的最大限制为 1.25 Gbps如果这些对云架构至关重要，则此限制可能需要向外扩展网关，也可能需要使用多个 专有网络(如果有 美国焊接学会）许多虚拟防火墙对它们可以处理的吞吐量或最大吞吐量有许可限制，即使在最高限制下也是如此此约束可能需要扩大防火墙的数量并以某种方式对其进行负载平衡。

建议

在建立吞吐量大小计算时，假设完整的DR容量负载捕获每个并发用户的以下数据：

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

对于上述指标,收集生产中与共识之间的当前流量模式相关的数据非常有用。同样重要的是要考虑与Citrix无关的其他数据流也会使用这些网络路径。请务必让网络和安全团队参与规划Citrix博士,以确保了解并适应遍历安全区域和网段的任何带宽估计值。当带宽非常高时,Citrix SD-WAN优化可以帮助减少有线会话占用空间或跨多个网络连接聚合带宽。

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

影响领域

成本

详细信息

对于在不同云平台上运行的 微软桌面操作系统实例，可能存在复杂的许可注意事项。微软修订了他们的云许可权于2019年8月发布,这可能会影响某些部署场景中的VDI成本影响。

建议

确定使用案例体系结构时，请参阅最新的 微软指南。如果灾难恢复解决方案中的 VDI存在潜在的成本挑战，请考虑在可行的情况下补充托管共享桌面（可能需要增强 RDS CAL）因为它们可以以较低的运营成本提供更大的灵活性。

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

影响领域

成本 可用性

详细信息

客户可以通过仅在需要时支付容量的吸引力来吸引云。此解决方案可以通过不为预留的基础架构付费而大幅降低灾难恢复成本，无论是否使用

但是，在大规模上，云提供商无法承诺同时打开数百或数千个虚拟机的 SLA如果灾难恢复的 VDA占用空间预计将落入数百或数千个实例，则此解决方案将变得特别具有挑战性。云提供商倾向于维持各种实例大小的现有批量容量；但是，该提供商可能会随时不同而有所不同。如果发生影响地理区域的灾难，也可能会有其他租户争用，也要求按需容量。

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

• 是否始终需要 100% 的 博士容量?
• 我们是否必须仅托管关键工作负载（即生产的子集）?
• 灾难恢复时向外扩展是可行的吗?如果是这样，博士级别是否对使用案例进行了优先级，以便更好地了解每个使用案例的不同 RTO以支持分阶段缩减容量?
• 我们是否可以扩展支持应用程序或托管共享桌面使用案例的操作系统实例,以节省配置时间并关闭这些实例的电源以节省运营成本吗?

建议

Citrix建议您首先与云提供商联系,以确定在RTO时间范围内打开预期容量的可行性,以及是否可以使用按需实例。为了避免灾难恢复方案中共识的容量可用性限制,Citrix建议在尽可能多的可用区域内配置的共识。在大规模上，可能值得跨不同云区域进行配置，并相应地调整架构。一些云提供商建议使用不同大小的虚拟机实例类型，以进一步减少虚拟机耗尽。在可能的情况下,谨慎的做法是预置VDA实例并使其脱机并定期更新。配置是一个资源和时间密集型过程,可以通过预置置备加快按需扩展VDA博士容量的速度。如果组织对容量可用性风险的兴趣不大，则可能需要应用预留或专用计算容量并相应地进行预算编制以保证资源可用性。通过引博士用恢复层,可以将按需模型和预留的\专用模型结合在一起,其中某些使用案例可能要求VDA立即可用,而其他用例可以灵活地在数天或几周的时间内恢复更长的RTO,如果它们对维持商业。

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

影响领域

成本 可用性 绩效

详细信息

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

建议

在可能的情况下，将应用程序和用户数据保持在 博士中的 Citrix平台本地，以便通过减少 广域网中的延迟和带宽需求，尽可能保持最佳性能。

Citrix云的灾难恢复规划

在灾难恢复规划方面，Citrix虚拟应用程序和台式机（CVAD）的本地部署或 “传统” 部署与 Citrix云提供的 Citrix虚拟应用程序和台式机服务 （CVADS）之间存在几个显着区别：

• Citrix为合作伙伴/客户管理大多数控制组件,从而免除了Citrix站点及其组件的重大灾难恢复要求。
• 为 Citrix资源部署灾难恢复环境只需要客户在恢复 “资源位置” 中部署 Citrix云连接器还需要为 Citrix网关部署 店面和 Citrix ADC
• Citrix云独特的服务架构在地理位置上是冗余的，并且从设计上讲具有弹性。
• 如果使用思杰工作区和思杰网关服务，则不需要访问层DR。

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

本节介绍了帮助客户为Citrix云定义适当灾难恢复策略的关键主题。

CVADS简化了灾难恢复

以下是一个典型的概念图，概述了CVADS的概念架构，以及思杰管理的组件和合作伙伴/客户管理的组件的责任分离。此处未说明WEM，分析和思杰网关“服务”，它们是与CVADS相关的选择Citrix云组件，属于“由思杰管理”的范围。

如图所示，需要恢复决策的控制组件中有很大一部分属于思杰的管理范围。作为一项基于云的服务，CVADS架构在Citrix云区域中具有高度的弹性。它是Citrix云”秘密酱”的一部分,并在Citrix云的 SLA中考虑。

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

• Citrix控制平面并访问 “服务”（如果使用中）（1）Citrix网关服务）。
• 客户。资源位置组件包括云连接器，VDA，应用程序后端，基础设施依赖项（AD，DNS等）和访问层（店面，的Citrix ADC）（如果不使用Citrix云访问层）。

在 CVADS上的灾难恢复方面，客户可以获得以下优势：

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

CVADS灾难恢复注意事项

尽管恢复计划的许多组件已从客户的管理范围中删除，但客户仍需对资源位置内组件的灾难恢复和高可用性（可选）的规划和管理负责。

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

前面灾难恢复选项讨论的大多数内容都适用于CVADS,因此有许多选择来适应组织恢复目标和预算。

在为Citrix云的CVADS服务规划灾难恢复时,需要从基础架构规划角度理解以下几项关键指导原则:

• 资源位置。生产和灾难恢复位置在 Citrix云中设置为独立的资源位置。
• 云连接器。每个资源位置必须至少部署两个云连接器。为清楚起见,云连接器不是灾难恢复事件期间必须手动或自动”恢复”的组件。它们必须被视为“热备用“组件,并在每个位置保持在线。
• 客户管理的访问控制器（可选）。出于多种原因,客户可以选择为Citrix网关和店面服务器部署自己的Citrix ADC,而不使用Citrix工作区或Citrix网关服务。这些可能包括：
  • 定制身份验证流
  • 增强了品牌推广
  • 更大的 HDX流量路由灵活性
  • 审计 伊卡连接和集成到 暹罗平台
  • 通过在店面中使用云连接器的本地主机缓存功能,在断开云连接器与Citrix云的连接时能够继续运行

  与云连接器一样,建议将店面和Citrix网关组件作为“热备用“部署在恢复位置,而不要在灾难恢复事件期间恢复它们。

操作注意事项

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

• Citrix博士平台不是非 戳使用“热备用“环境的客户可能很想把灾难恢复视为测试平台。这种处理对解决方案的完整性产生负面影响。事实上，灾难恢复可能是最后一个推广更改的平台，以确保在维护发生灾难性错误的情况下，在非生产环境中未显示出来的情况下，灾难恢复可能会确保其效用不受影响。
• 修补和维护。使用“热备用”思杰平台时，与生产锁步进行日常维护对于维护功能齐全的灾难恢复平台至关重要。在操作系统，思杰产品和应用程序修补程序方面保持灾难恢复与生产同步非常重要。为了降低风险，建议在修补生产和修补DR之间留出几天到一周的时间。
• 定期测试。无论灾难恢复是涉及将生产复制到恢复设施还是使用“热备用”环境，都必须定期测试（理想每年两次或更长时间）灾难恢复计划，以确保团队熟悉恢复过程以及平台或工作流中的任何缺陷已确定并补救。
• 能力管理。对于主动——被动和主动”始终打开“Citrix环境,灾难恢复也必须考虑生产中的容量或用例更改。特别是在使用active - active模型时,资源利用率很容易提高到超过每个环境中资源的50%稳定状态利用率阈值,仅适用于发生灾难恢复事件和幸存平台变得不堪重负并且性能不佳或由于超载。容量可以每月或每季度进行审查。

摘要

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

• 了解客户环境的业务需求和技术能力会影响Citrix所需的灾难恢复策略。选择的恢复策略可以与业务目标保持一致。
• 高可用性并不等同于灾难恢复。但是，灾难恢复可能包括高可用性。
• 在物理位置之间共享管理边界并不构成灾难恢复解决方案。
• 为组织的技术产品组合开发灾难恢复分层分类可在制定恢复战略时提供可见性、灵活性和潜在的成本节约。
• Citrix基础架构或托管在Citrix上的应用程序的RTO要求是需要进行灾难恢复设计的最重要影响因素。更短的RTO通常需要更高的解决方案成本。
• 思杰的灾难恢复体系结构不采用“热”灾难恢复平台，限制了客户可以使用的技术，例如思杰MCS，ADC和供应。
• Citrix的灾难恢复策略还需要考虑用户数据和应用程序后端的恢复和恢复时间。Citrix可以被设计为快速恢复,但是,如果应用程序和数据依赖关系在类似的时间范围内不可用,用户仍可能无法工作。
• 云环境中的灾难恢复有自己的注意事项，组织必须审查本地环境中不存在这些考虑因素，以避免在云环境中调用灾难恢复时出现意外的瓶颈或运营影响。
• 必须保持灾难恢复组件的最新状态，以匹配生产更新和配置，以维护平台的完整性。
• 在不同位置之间使用Citrix的主动——主动配置的平台必须注意容量监控,以确保在发生灾难时,有足够的资源可用于支持一个或多个幸存位置的预计负载。
• 客户必须定期测试 Citrix的灾难恢复计划，以验证其运行情况以及实现其核心目的的能力。
• Citrix虚拟应用程序和桌面服务大大简化了灾难恢复架构的许多方面,并允许通过区域首选项配置实现资源位置冗余。

来源

本文的目标是帮助您规划自己的实施。为了使这项任务更加简单，我们希望为您提供可以根据自己的需求调整的源图：源图。