参考架构:Citrix DaaS-AWS

受众和目标

本文档旨在帮助 Citrix 合作伙伴和客户了解在 Amazon 公有云上成功部署 Citrix 虚拟化技术所必需的最关键的设计决策。它并不意味着“操作方法”参考-Citrix 会考虑这些 部署指南,它们现在与 参考体系结构分开交付和维护。在本文档中,我们使用 Citrix 架构设计框架来组织和展示 Citrix 和精选 Citrix 咨询合作伙伴使用的主要实践、建议和设计模式。

概述和执行摘要

近三十年来,Citrix 虚拟化和网络技术一直成功满足大小企业的需求。这些技术可以通过多种方式获得许可、部署、集成和管理。这种灵活性使 Citrix 技术能够为各种不同的使用案例、业务类型、集成要求和运营模式提供服务。本白皮书面向考虑或计划在 AWS 的公有云基础架构上部署这些技术的 Citrix 客户或合作伙伴。

对于希望实现基础架构现代化的现有客户和希望部署 Citrix 虚拟化和网络技术的新客户,必须在此过程中做出几项关键的高级和低级决策,以帮助促进成功部署。为了帮助客户和合作伙伴了解这些决策点,我们引入并定义了一些特定术语来设置适当的上下文,然后使用此上下文突出说明在规划部署时要考虑的关键决策和影响。

我们首先定义了两种主要的技术采用模式: 客户托管 模式和 云服务。然后,我们 将 Citrix 虚拟化系统的组件 分解为多个子系统,并按采用模式对它们进行分类:

采用模式/子系统功能 客户托管(从下载的二进制文件中安装) 云服务(通过 Citrix Cloud 提供)
会话代理和管理 Citrix Virtual Apps and Desktops (CVAD) Citrix DaaS (DaaS)
用户界面 (UI) 服务 Citrix StoreFront Citrix Workspace(该服务,通过 Citrix Workspace 应用程序或 Web 浏览器使用)
身份验证 Citrix StoreFront(加上大多数使用案例的 Citrix ADC/Gateway) Citrix Workspace(对于某些使用案例,加上 Citrix ADC/Gateway)
HDX 会话代理 Citrix ADC/Gateway Citrix Gateway 服务

我们采取 云服务的立场,建议 大多数组织在可行的情况下使用或计划使用云服务 。我们并不盲目地提供这种立场-尽管我们确实认为云服务最终会为我们的客户带来极大的积极好处,但我们认识到,并 非所有组织/部署今天都能将云服务用于所有子系统。有时,使用案例要求(具有技术属性或当前可用/特定云服务中的缺陷)需要结合使用云服务和客户管理组件:本白皮书将重点介绍这些内容。在其他情况下,非技术性项目(政治、预算/合同考虑、云就绪性缺陷、监管/合规性考虑等)可能会阻碍云服务的使用。在这些情况下,我们建议您与 Citrix 合作伙伴/销售/工程团队合作,以帮助克服这些问题。通过本白皮书的其余部分,我们将竭尽全力确定关键功能、功能或属性,以帮助客户决定何时将哪种采用模式用于哪个子系统。

接下来,我们定义并检查三种常见的部署方案,重点介绍每个子系统使用的采用模式:

  • Greenfield/仅限 Cloud -将云服务用于所有 Citrix 虚拟化系统子系统,以及 AWS 公有云服务。
  • 混合 (不要与“混合云”混淆)-最常见的部署模型,混合模型使用DaaS进行会话代理和管理,其余子系统同时提供客户托管和云服务选项。
  • 直接迁移 - 顾名思义,此模型使用现有的、客户管理的 CVAD、StoreFront 和 ADC/Gateway,要么按原样将这些组件迁移到 AWS,或者作为向 AWS 公有云服务的工作负载迁移的一部分将它们安装到 AWS 中。虽然这对于某些特定用例来说是有效的部署模型,但它附带了实质性的警告。

最后,我们使用记录良好的 Citrix 架构设计框架 来组织和展示在 AWS 上部署 Citrix 虚拟化技术时要考虑的关键设计决策。为了清楚起见,我们将重点放在“Citrix on AWS 的不同之处”上,并根据需要提供指向其他资源的链接以获取更多详细信息。

我们最终建议大多数客户从第一天起使用 混合部署模型 ,使用 CVAD 服务进行 会话代理和管理。这为客户提供了在 AWS 上经济高效地运行 Citrix 虚拟化系统所需的关键功能,大幅降低了成本和复杂性,提供了对最新可用特性和功能的访问,并简化了向未来。云服务或客户托管组件可用于其余子系统(取决于客户的具体需求),但我们建议客户清楚为什么他们使用客户托管组件,并计划在未来云服务迁移到云服务满足他们的特定需求。

有关 Citrix on AWS 领先实践的更多见解,读者可以参阅以下云指导文章:

关键概念和部署场景

在本节中,我们将介绍一些关键概念和部署方案,然后再深入探讨 Citrix 架构设计框架每个层的具体注意事项。

技术采用模型

Citrix DaaS 技术可以通过多种不同的方式“使用”或实施。最常见的方法通常可以描述为“客户托管”和“云服务”。还值得一提的是第三种模式- 合作伙伴托管。为了清楚起见,我们在这里描述这个模型,但从建筑设计的角度来看,前两个模型最相关。

为什么我们在参考架构中讨论技术采用模型?采用模式或“消费”模式的选择对系统设计、功能、成本和管理责任的划分具有重大影响。本节将定义和探索这些模型,并提供一些一般性指导,以帮助客户在设计 Citrix 虚拟化系统时做出明智的选择。

客户托管

多年来,想要使用技术的企业别无选择,只能购买、安装、配置和维护构建 Citrix 虚拟化系统所需的整个技术堆栈。Citrix 的虚拟化软件仅作为可安装的二进制文件提供。 购买 Citrix 虚拟化软件的客户将下载这些二进制文件(通常采用可下载的 ISO 磁盘映像或自解压可执行文件的形式),然后自行安装、配置和维护软件。Citrix 软件(和网络硬件)通常安装在客户拥有和维护的基础架构中,而客户也拥有和维护的数据中心。

从概念上讲,Citrix 虚拟化系统由各种不同的 Citrix 组件组成,我们在本文中详细描述了其中许多组件。它们还需要不同层的第三方组件,必须先提供这些组件,然后才能使用 Citrix 位执行任何操作。最终,他们共同创建了一个功能齐全的 Citrix 虚拟化系统。为清楚起见,本文档将此技术采用模式称为“客户管理”。 我们使用此术语来描述 Citrix 虚拟化系统中的各种不同组件,包括 Citrix 组件下层、旁边和“上方”层中必需的第三方组件。这种模型也可以称为“自我管理”。

如今,客户拥有替代客户托管采用模式的引人注目的替代方案,但是出于各种原因,有些客户仍然使用此模型采用其技术堆栈尽管此模型为客户提供了对 每个组件的最大控制权,但其代价是:客户承担管理和维护组件的责任,包括保护、操作、修补、升级和维护高可用性。此模型 通常还用于“空格”系统 (那些没有任何 Internet 访问权限的系统,因此使用云服务的能力受到限制,这些服务通常可通过公共网络安全访问)。

以下是 Citrix 虚拟化系统的架构示例,该系统使用使用弹性计算云 (EC2) 和虚拟私有云 (VPC) 网络等基本 AWS IaaS 服务部署在 AWS 上的 100% 客户托管组件。我们将在本文档的后面部分讨论此架构的一些细节,尽管您可以立即注意到与更简单的绿地/仅云部署模型的相似之处:

图 1:100% 客户托管、仅使用 AWS 作为 IaaS 的升降/班次部署图 1:100% 客户托管、仅 使用 AWS 作为 IaaS 的提升/班次部署。

云服务

在过去 15 年中,许多不同领域的技术进步带来了超大规模的公共云、复杂的云服务、微服务架构、DevOPS/Agile 交付框架、订阅许可模式以及“长青”软件和系统。 这些进步彻底改变了世界上几乎每个行业获取、采用、交付和维护技术的方式。

今天,构成 Citrix 虚拟化系统的许多组件或层都可以“作为服务”使用。与“客户管理”采用模式(客户将技术作为企业资产购买并自行构建/维护系统)相反,客户“订阅”各种服务,服务提供商承担提供和管理这些服务的责任。这些服务通常通过公共网络(即 Internet)消费,导致一些人称之为“云服务”或“Web 服务”采用模式。在本文中,我们将把这种类型的采用模式称为“云托管服务”,或者简单地称为“云服务”模式。

Citrix 提供了许多传统产品“即服务”,利用其平台合作伙伴的最新技术进步简化和简化采用,加快创新步伐,提高质量,并随着时间的推移为客户提供更多增量价值。Citrix 将此服务交付平台称为“Citrix Cloud”,它代表了 Citrix 当前和未来的最新发展。

以下是一个系统的架构示例,该系统使用 100% 云服务组件进行 AWS 上的 Citrix 虚拟化系统。 我们将在本文档的后面部分讨论此设计的细节:

图 2:使用 AWS 托管服务的 AWS 上的 100% 云服务图 2:使用 AWS 托管服务的 AWS 上的 100% 云服务

合作伙伴托管

尽管许多组织选择构建自己的 Citrix 虚拟化系统,但一些客户希望摆脱管理 IT 的业务,以便他们可以将资源和注意力集中在为自己的客户和市场提供服务上。为了服务这些客户,Citrix 与使用 Citrix 技术为其客户提供“成品”服务的集成合作伙伴合作。

定义和区分可用的不同集成合作伙伴/类型和产品不属于本文档的讨论范围。但是,Citrix 合作伙伴在设计 Citrix 虚拟化系统时面临的选择与客户面临的同样Citrix 合作伙伴可以选择使用 Citrix Cloud 提供的一项或多项服务,也可以选择根据客户的特定需求构建和管理系统的某些组件。因此,本文档中提供的指导与 Citrix 合作伙伴及其客户相关,原因不同。

Citrix 虚拟化系统组件

为了理解本文档后面详细介绍的设计决策的含义,我们将将 Citrix 虚拟化系统的组件放入更高级别的“存储桶”中,然后我们将用来指导您的决策过程。每个 Citrix 虚拟化系统,无论如何部署和许可,都需要这些组件才能正常运行并提供最佳、最安全的用户体验。客户混合搭配自我管理组件和云服务并不罕见,尤其是在他们有复杂的使用案例要求、第三方集成要求或极端控制或可用性需求的情况下。

为清楚起见,下表突出了这些关键组成部分。本文档后面将介绍有关何时/何地使用一种选项而不是另一个选项的详细信息和建议:

采用模式/子系统功能 客户托管(从下载的二进制文件中安装) 云服务(通过 Citrix Cloud 提供)
会话代理和管理 -任何 Citrix 虚拟化系统的核心:没有此核心子系统,您就没有任何应用程序或桌面,也无法管理它们!您可以在此子系统中定义、配置和更新计算机目录(Citrix 虚拟交付代理或“VDA”虚拟机实例的集合)。您还可以在其中创建交付组、将应用程序/桌面分配给用户以及管理环境和用户会话。 CVAD - Citrix Virtual Apps and Desktops,长期服务版本 (LTSR) 或当前版本 (CR) 版本。如果您在环境中安装并配置 Delivery Controller,则这就是您正在运行的。这也意味着您正在安装和管理自己的 Microsoft SQL Server 基础架构。客户托管 (CVAD) 部署中的管理功能包括 Citrix Director 和 Citrix Studio。您可以使用 LTSR/CR 二进制文件自行安装、配置和管理这些文件。Director 还需要Microsoft SQL Server 基础架构。Citrix 许可也是此子系统的一部分,客户可以安装/配置/管理 Citrix 许可证服务器和许可证文件。 DaaS - Citrix DaaS,通过 Citrix Cloud 交付。如果您要登录 Citrix Cloud 并在环境中安装和注册Cloud Connector,则表示您正在使用此 Citrix Cloud 服务。您可以在管理的 Windows 实例上安装和注册Cloud Connector,然后 Citrix 将这些实例保持常绿并可用。Citrix Cloud 还通过 Citrix Cloud 控制台通过 Web 浏览器提供和维护大多数管理功能。这包括 Citrix Studio 和 Citrix Director 的云服务版本。客户没有额外的基础架构可以维护、保持高可用性或修补/更新:Citrix 负有此管理责任。
UI(用户界面)服务 -本机 Citrix Workspace 应用程序(以及用于无客户端访问的 Web 浏览器)最终连接到 URL。URL 背后的子系统由 IT 管理员配置,以满足公司对身份验证的要求,并展示虚拟化应用程序/桌面、SaaS 应用程序,以及可能更多供用户访问的其他内容。 Citrix StoreFront。此外,此角色还通过 CVAD LTSR 或 CR 二进制文件安装/配置,为最复杂的部署方案提供了极大的灵活性。通常成对部署,Citrix ADC/Gateway 实例在其前面以实现高可用性。可以聚合和呈现来自客户托管/代理环境 (CVAD) 和 Citrix Cloud 托管/代理环境 (DaaS) 的应用程序和桌面。 Citrix Workspace (服务,而不是 Citrix Workspace 应用程序)。通过 Citrix Cloud 作为云服务提供,并包括许多仅在此服务中可用的下一代功能。可以聚合和呈现来自客户托管/代理环境 (CVAD) 和 Citrix Cloud 托管/代理环境 (DaaS) 的应用程序和桌面。
身份验证 -在这种情况下,我们指的是用户在访问 Citrix 虚拟化应用程序/桌面、文件、SaaS 应用程序等之前如何进行身份验证。Citrix 环境中的身份验证通常在 UI 服务层配置,尽管 Citrix ADC/Gateway 也可用于所有部署模型中的身份验证。每个 UI 服务提供商选项(Citrix StoreFront 或 Citrix Workspace)都有不同的身份验证选项,其中一些选项需要客户管理的 Citrix ADC/Gateway。 Citrix StoreFront (加上大多数使用案例的 Citrix ADC/Gateway )。尽管最终需要 Active Directory 实例和有效的用户帐户,但可以使用不同的方式提供用户身份验证服务客户通常管理 AD 实例。Citrix ADC/Gateway 实例还可用于提供身份验证服务,并提供大量通常用于更复杂的环境的高级功能。还可以安装 Citrix 联合身份验证服务 (FAS),并使用它们为复杂的用例提供会话 SSO。 Citrix Workspace (对于某些使用案例,还有 Citrix ADC/Gateway )。使用 Citrix Workspace(服务),只需为 Citrix Cloud 租户配置一次用户身份验证源和要求,并由使用此 URL 的所有用户使用。它是为 Active Directory 配置开箱即用的,但对于高级用例,可以将其配置为支持其他身份验证提供程序。示例包括 Azure AD、Okta、客户托管的 Citrix Gateway、Google Cloud ID 或其他 SAML/OpenID/RADIUS 提供商。某些情况需要客户管理的 Citrix ADC/Gateway 和 Citrix 联合身份验证服务 (FAS) 才能获得最佳的用户体验。
HDX 会话代理 -能够安全、无缝地将企业专用网络之外的用户/设备连接到内部的 CVAD/DaaS 交付的应用程序和桌面。 Citrix ADC/Gateway 设备-这些设备(或实例)通常为 Citrix 虚拟化系统提供大量额外功能。但是,他们的核心任务是在客户端处于公共网络上时,将 HDX 会话安全地代理到 VDA。需要安装、配置、SSL 证书等。兼容 StoreFront(客户托管的 UI 服务)和 Workspace 云服务。还兼容 Citrix 托管和客户管理的会话代理选项。 Citrix Gateway 服务 -由 Citrix Cloud 提供,该服务将 HDX 会话流量代理到您的 VDA,并使用 Citrix 托管基础设施完成工作。无需公共 IP 地址、SSL 证书或入口防火墙规则即可运行。兼容 Citrix Workspace Service 以及 Citrix Cloud 托管和客户托管的会话代理选项(CVAD 和 DaaS)。

领先的实践和建议

无论您是自己管理 Citrix 虚拟化系统,还是使用 Citrix 或授权合作伙伴进行管理,请考虑尽可能使用 云服务 。对于云服务无法满足您的需求的使用案例/环境,可以使用客户托管组件。也就是说-Citrix 鼓励客户清楚为什么要部署自我管理组件,并准备好在云服务满足其特定需求后迁移到云服务。Citrix 通过 Citrix Cloud 提供的云服务正在迅速发展。随着时间的推移,您可以期待它们提供服务除最复杂的用例外的所有用例所需的所有功能。Citrix Cloud 服务最终最大限度地减少了客户负责管理和维护的基础设施的数量。Citrix Cloud 还提供高度可用的预集成服务,并确保客户始终能够访问最新、最安全且功能丰富的服务。

AWS 上 Citrix 虚拟化的常见部署模型

作为一家拥有最多功能、最大客户社区、无与伦比的体验和成熟度的云提供商,AWS 看到来自不同行业的广泛客户将系统和基础设施迁移到云中。随着时间的推移,他们看到了常见的部署场景/迁移模式的发展。在本节中,我们将探讨这些模式/场景,讨论您可能希望在何时何地考虑使用它们将 Citrix Virtual Apps and Desktops 工作负载引入 AWS,并为常见迁移方案应考虑哪些模式提供一些建议。

在 AWS 上交付 Citrix 应用程序和桌面的三种最常见的场景是:

  • Greenfield /仅限云 部署,将 Citrix Cloud 服务与 Amazon EC2(Amazon Elastic Compute Cloud)服务上的“资源位置”结合使用。当客户希望使用订阅模式并将控制平面基础架构和管理责任外包给 Citrix,或者他们希望体验/评估 Citrix Cloud 服务提供的功能时,通常会使用此方案。
  • 混合部署/工作负载迁移到 AWS,使用 Citrix Cloud 服务进行会话代理和管理,Workspace UI 或 StoreFront 进行内容聚合/会话演示/会话启动,还可以使用客户管理的 Citrix ADC/Gateway 进行 HDX 会话代理,复杂身份验证方案或两者兼而有
  • 抬起并移动。在这种情况下,客户基本上将自我管理的 Citrix 基础设施移动或重新部署到 AWS 中,将 AWS 上的部署与现有的客户托管部署一样对待。在这种情况下,客户可以使用 Citrix ADC/Gateway 和 Citrix StoreFront 聚合来自本地和 AWS 托管站点的资源。这有助于将工作负载迁移到 AWS,尽管客户可以保留本地工作负载,只需在 AWS 中添加另一个站点即可。新站点可用于处理新的工作负载,也可用于支持灾难恢复 (DR) 和故障切换使用案例。此模型的特点是使用客户托管组件进行会话代理和管理、UI 服务、身份验证和 HDX 会话代理。

本节更详细地定义了这些场景,包括对每个场景的通常设计方式的架构概述。 您发现 主要的做法是使用 Citrix Cloud 服务,因此本文档将重点介绍 Citrix Cloud 中介的部署模型(“格林菲尔德”和“混合”)。

格林菲尔德部署

绿色现场部署模型最常见的示例是在 AWS 云上试用或概念验证部署 Citrix 虚拟化技术。由于您基本上是从头开始的,因此可以体验到“基础设施即代码”的力量,因为您不想与一堆现有的“东西”集成。这也是“使用”各种云服务并评估它们是否适合您或您客户的需求的绝佳机会。

绿色现场部署也是您可以构建的最快捷、最简单的 Citrix 虚拟化系统。当系统不再需要时,您可以简单地将其拆除,然后停止为其消耗的资源付费。此类部署所需要的只是一个有效的 AWS 帐户,以及试用版或付费订阅 Citrix Cloud 和 Citrix DaaS。有了这两种资源,您可以使用 AWS 的 QuickStart CloudFormation 模板构建参考部署。Citrix 和 AWS 合作开发了 Citrix DaaS on AWS 快速入门模板,该模板可帮助您从头开始构建整个 Citrix 虚拟化系统,或者在具有现有 Active Directory 的现有 VPC 中创建 Citrix Cloud“资源位置”。从头开始部署整个 Citrix 虚拟化系统时,AWS 上生成的系统与以下参考架构图非常匹配:

图 3:已部署的系统架构详细说明了默认参数。未显示 Citrix Cloud 服务 图 3:使用 Citrix DaaS on AWS 快速入门模板和默认参数部署的系统架构详细信息。未显示 Citrix Cloud 服务。

图 4:带有可选 AWS 服务和 Citrix Cloud Services 的“仅限 Greenfield/Cloud 部署概念体系结构 图 4:带有可选 AWS 服务和 Citrix Cloud Services 的仅限 Greenfield/Cloud 部署概念体系结构。

值得注意的是,此部署模型(实际上是所有三种部署模式)使用 AWS 可用区 来提供高度可用的设计。有关更多背景信息,请参阅本文档后面的 可用区

如前所述,学习 AWS 和 Citrix Cloud 服务时,这是一个很好的开始。上图中描述的许多设计模式都用于混合、甚至直接迁移部署类型,因此无论部署模式如何,学习这些设计模式都适合 Citrix on AWS 架构师。

总之, 绿色现场部署模型 使用所有云服务,至少作为起点:

Citrix 虚拟化系统组件 提供方:
会话代理和管理 Citrix DaaS(“DaaS”,通过 Citrix Cloud)
UI 服务 Citrix Workspace Service(通过 Citrix Cloud)
身份验证 Citrix Workspace Service(通过 Citrix Cloud)
HDX 会话代理 Citrix Gateway 服务(通过 Citrix Cloud)
虚拟机计算、网络和存储 Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Virtual Private Cloud (Amazon VPC)、Amazon Elastic Block Store (Amazon EBS)
Active Directory 和文件系统 适用于 Microsoft Active Directory 的 AWS Directory Service适用于 Windows 文件服务器的 Amazon FSx(可选)

我们之前提到,绿色现场部署模型通常被用作概念验证和技术试验系统的起点。 如果您从此模型开始,然后放入 StoreFront 或 Citrix ADC/Gateway VPX,那么表面上您正在创建我们的下一种类型的部署模型:混合。

混合部署

使用混合部署模式,客户可以选择自己安装/配置/管理某些 Citrix 虚拟化系统组件 ,但不能选择 会话代理和管理子系统。在混合部署模型中,此子系统作为名为“Citrix DaaS”的云服务提供,并作为 Citrix Cloud 的订阅提供。

混合部署模式是当今最常见的部署,也是 Citrix 为大多数客户推荐的模式。以下是我们采取这一立场的一些主要原因:

  • 简单性 -使用 Citrix Cloud 服务,简单性是基本的设计原则。当使用多个云服务时,它们会预先配置为协同工作,如果需要配置,工作流程和选项将大大简化。
  • 基础架构和许可成本节省 -客户管理的 Citrix 虚拟化服务通常需要额外的硬件和软件来支持它们,而且这些成本会产生与之相关 Microsoft SQL Server 就是一个很好的例子:客户管理的代理和管理服务需要数据库,如果您要构建/管理自己的数据库,您必须提供它们。另一种方法是使用适用于 SQL Server 的 AWS 关系数据库服务 (Amazon RDS)。
  • 自动扩缩 ——Citrix 的托管代理服务 (DaaS) 包含 Citrix AutoScale 功能,该功能提供内置的 VDA 容量和成本管理功能。当客户只为使用的内容付费时,此功能可以为客户节省大量基础架构资金。在 AWS 上运行 Citrix 虚拟化工作负载时,这通常意味着为承诺使用折扣付费或随时支付虚拟机使用量之间的区别。对于许多使用案例而言,成本节约可能会显著,而 Citrix Autoscale 功能可帮助确保您只消耗所需的内容。
  • 节省管理费用 - 借助云服务,Citrix 肩负着保持服务的高可用性、高性能、安全性和最新性的责任。无论如何,您仍然可以构建和管理自己的 VDA,但不要低估委派这些责任的价值。云服务有助于释放 IT 资源,使他们能够专注于为业务提供独特的价值,而不是这些关键但繁琐(通常是耗时的)任务。
  • “免费”升级和持续创新 -借助客户托管的基础架构,客户有责任升级和修补其所服务的组件。借助云服务,大部分这些工作努力都会消失。服务提供商(例如 Citrix 或 AWS)往往会不断创新,他们将这些创新带给使用服务的客户,通常不需要代表客户进行任何工作。
  • 获取更多功能、功能和服务 - 现代服务交付平台(例如 Citrix Cloud 和 AWS EC2)为技术提供商提供了一种强大、经济高效的方式,将新功能、功能和服务推向市场,而这种方式将无法实现的新功能、功能和服务。Citrix 等供应商致力于在数字化转型之旅中的任何地方与客户见面,但有时候,经济高效地提供新功能的唯一方法是将其作为云服务提供。
  • 灵活性 -借助 DaaS 作为此部署模型的基础,客户可以混合搭配 Citrix 虚拟化系统的客户托管或云服务组件。这使系统能够满足各种不同的用例,并支持 Citrix 虚拟化系统的复杂企业要求。我们将在本文后面的章节中深入探讨这些选择。

总之, 混合部署模型 使用以下内容:

Citrix 虚拟化系统组件 提供方:
会话代理和管理 Citrix DaaS(“DaaS”,通过 Citrix Cloud)
UI 服务 Citrix Workspace Service(通过 Citrix Cloud) Amazon EC2 上的 Citrix StoreFront(客户托管)
身份验证 Citrix Workspace Service(通过 Citrix Cloud) EC2 上的 Citrix StoreFront(Citrix ADC/Gateway 可选但常见)
HDX 会话代理 Citrix Gateway 服务(通过 Citrix Cloud) Amazon EC2 上的 Citrix ADC/Gateway VPX(Citrix ADC/Gateway 可选但常见)
虚拟机计算、网络和存储 Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Virtual Private Cloud (Amazon VPC)、Amazon Elastic Block Store (Amazon EBS)
Active Directory 和文件系统 适用于 Microsoft Active Directory 的 AWS Directory Service适用于 Windows 文件服务器的 Amazon FSx(可选)

考虑到客户可以在混合部署模式中选择的选项,以及客户托管组件提供的灵活性,因此没有一种简洁的体系结构适合所有客户。但是,有一些常见的设计模式也可以混合/匹配以满足客户的需求。但是,基本模式是 AWS 上 Citrix Cloud“资源位置”的模式。它也是由 Citrix DaaS on AWS 快速入门模板构建的模式,其外观类似于以下架构图:

图 5:概念架构、Citrix DaaS——AWS 上的混合部署模型 图 5:概念架构、Citrix DaaS——AWS 上的混合部署模型。

值得注意的是,此部署模型还使用 AWS 可用区 来提供高度可用的设计。有关更多背景信息,请参阅本文档后面的 可用区

还值得注意的是,混合部署模式(AWS 上的 DaaS 资源位置)可以与混合云模型相结合,使用 AWS Direct Connect、AWS VPN 或其他联网工具将客户托管的数据中心/资源连接到 AWS。使用此模型,客户现有的 Active Directory 通常扩展到 AWS,客户可以创建更多 Citrix Cloud“资源位置”,从客户托管的数据中心交付应用程序、桌面和资源。生成的概念架构如下图所示: 图 6:概念架构、Citrix DaaS:混合部署/混合云模型 图 6:概念架构、Citrix DaaS:混合部署/混合云模型。

直接迁移

参照我们对 Citrix 虚拟化系统组件的定义,当我们谈论直接迁移部署方案时,关键组件是会话代理和管理子系统以及相关的基础架构。如果您使用的是自我管理的代理基础架构 (您正在部署 Delivery Controller 而不是 Cloud Connector),那么为了本白皮书的目的, 您将提升和转移。

直接迁移 - 原因

尽管 Citrix 针对此模型提供了指导,但一些客户仍然选择使用此模型并自行部署/管理 Citrix 虚拟化系统组件。根据 CTX270373,只有 LTSR 产品版本支持使用包括 AWS 在内的公有云。对于选择直接迁移(自我管理)部署模式的客户,我们经常发现其背后存在非技术原因。政治、时间压力、对未知的恐惧、感知的技能短缺、失控和获得许可证都属于这一类。但是,这种模型具有吸引力,有几个技术原因。这些措施包括:

  • 系统隔离 - 某些使用案例,例如没有 Internet 访问 的空气间隙系统,通常会使直接迁移模式具有吸引力。由于云服务需要出站 Internet 访问才能正常运行,因此在严格的空气间隙部署中,云服务将无法正常运行。这主要适用于Cloud Connector(托管会话代理服务的主要组件),因为他们需要出站 Internet 连接才能与 Citrix Cloud 服务进行通信和使用。有些客户可以考虑为 Cloud Connector 使用安全的出站代理(同时保持所有其他基础设施严格的空隙)。这通常是允许利用托管代理服务的合适让步,但即使这对于某些客户和使用案例来说也可能不是一种选择。
  • 配置灵活性 -一个人的“复杂”是另一个人的“灵活性”,二十多年来,灵活性一直是客户管理的 Citrix 虚拟化基础架构的强大套件。多年来,该技术获得了大量支持非常小众的用例和第三方集成的功能。Citrix Cloud 服务侧重于简单性和预集成。在这样做时,其中一些利基功能和集成不可用。因此,一些边缘案例仍然最好由客户管理的堆栈提供服务。也就是说,鉴于 Citrix Cloud 服务的创新速度快,这些边缘案例变得越来越罕见。
  • 控制 -一些组织、文化和商业模式需要尽可能多的控制。借助客户管理的 Citrix 虚拟化组件,客户可以完全掌握自己的命运。这种控制需要付出代价(基础架构、复杂性、人员等),但“不惜一切代价控制”对于某些客户来说是一件事。

总之,直接迁移部署模型使用以下内容:

Citrix 虚拟化系统组件 提供方:
会话代理和管理 Amazon EC2 上的 Citrix Virtual Apps and Desktops(客户使用 LTSR 或 CR 可下载管理)
UI 服务 Amazon EC2 上的 Citrix StoreFront(客户托管)
身份验证 EC2 上的 Citrix StoreFront(Citrix ADC/Gateway 可选但常见)
HDX 会话代理 Amazon EC2 上的 Citrix ADC/Gateway VPX(客户托管)
虚拟机计算、网络和存储 Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Virtual Private Cloud (Amazon VPC)、Amazon Elastic Block Store (Amazon EBS)
Active Directory 和文件系统 客户在 EC2 上托管 Windows Server 实例;适用于 Microsoft Active Directory 的 AWS Directory Service适用于 Windows 文件服务器的 Amazon FSx(可选)

在最简单的形式中,将 Citrix 虚拟化技术的部署直接迁移到 AWS 上,类似于传统的本地客户托管部署。它使用部署到 AWS 区域的 CVAD“站点”,并至少使用基本的 AWS IaaS 服务,例如 EC2 虚拟机和 VPC 联网。如前所述,它要求客户构建/配置/维护所有系统组件,以及诸如 SQL 数据库之类的支持服务。下图描述了此部署模型: 图 1:概念架构、CVAD:AWS 上的直接迁移部署模型 图 1:概念架构、CVAD:AWS 上的直接迁移部署模型。

值得注意的是,此部署模型还使用 AWS 可用区 来提供高度可用的设计。有关更多背景信息,请参阅本文档后面的 可用区

直接转移部署模式通常与混合云基础设施模型相结合,使用 AWS Direct Connect、AWS VPN 或类似的网络技术将客户管理的数据中心和资源连接到 AWS。客户可以选择采用 AWS 的一些更高级的云服务(以便在过渡过程中提供一定程度的简化),他们还可以选择在 AWS 上在客户托管的数据中托管某些服务(例如 SQL 数据库、Citrix 许可、Citrix StoreFront 和 Citrix ADC/Gateway)中心,或两者取决于他们的现有投资、使用案例要求等。下图显示了此部署模型的概念架构(使用 AWS RDS for SQL Server 或本地 SQL Server)。只需要一个活动的 Citrix Licensing 实例,但我们已经展示了多个实例来描述可用的选项: 图 8:概念架构、CVAD:使用混合云基础设施模型和 AWS 托管云服务的直接迁移部署 模型图 8:概念架构、CVAD:使用混合云基础设施模型和 AWS 托管云服务的直接迁移部署模式。

直接迁移 - 为什么不

到目前为止,您已经收集到 Citrix 的主要实践/建议是不要完全直接迁移。您可能想知道为什么,或者这是从哪里来的。参考我们对 Citrix虚拟化系统组件的细分, 会话代理和管理 子系统是您要考虑的最关键的组件,而不是提升和移动。我们强烈建议客户考虑使用 Citrix 的云服务进行会话代理和管理(仅部署 Cloud Connector,而不是部署 Delivery Controller + SQL 数据库 + Director 服务器 + Citrix 许可服务器)。以下是我们采取这一立场的一些主要原因(他们可能听起来很熟悉):

  • 简单性 - 虽然客户管理的会话代理服务 提供了最终的控制和配置灵活性,但它的代价是复杂性和持续维护需求。借助 Citrix Cloud 服务,简单性是基本的设计宗旨。当使用多个云服务时,它们会预先配置为协同工作,如果需要配置,工作流程和选项将大大简化。
  • 基础架构和许可成本节省 -客户管理的 Citrix 虚拟化服务通常需要额外的硬件和软件来支持它们,而且这些成本会产生与之相关 Microsoft SQL Server 就是一个很好的例子:客户管理的代理服务需要数据库,如果您要构建/管理自己的数据库,您必须提供它们。
  • 说到基础设施成本节省,这在两种会话中介选项 之间提供了一个关键的区别因素: AutoScaling。Citrix 的托管代理服务 (DaaS) 包括 Citrix AutoScale 功能,该功能提供内置的 VDA 容量和成本管理功能。当客户只为使用的内容付费时,此功能可以为客户节省大量基础架构资金。在 AWS 上运行 Citrix 虚拟化工作负载时,这通常意味着为承诺使用折扣付费或随时支付虚拟机使用量之间的区别。对于许多使用案例而言,成本节约可能会显著,而 Citrix Autoscale 功能可帮助确保您只消耗所需的内容。重要说明: 此功能仅适用于 Citrix Cloud 服务 (Citrix DaaS) 客户,不适用于客户托管的代理基础架构(Citrix Virtual Apps and Desktops LTSR 或 CR 版本)。 - 节省管理成本 -借助云服务,Citrix(在本例中为 AWS)负责保持服务高可用性、高性能、安全性和最新性。无论如何,您仍然可以构建和管理自己的 VDA,但不要低估委派这些责任的价值。云服务有助于释放 IT 资源,使他们能够专注于为业务提供独特的价值,而不是这些关键但繁琐而且通常耗时的任务。
  • “免费”升级和持续创新 -借助客户 托管的基础架构,客户有责任升级和修补其所服务的组件。借助云服务,大部分这些工作努力都会消失。服务提供商(在这种情况下为 Citrix 和 AWS)往往不断创新,他们将这些创新带给使用服务的客户,通常不需要代表客户进行任何工作。
  • 获取更多功能、功能和服务-现代服 务交付平台(如 Citrix Cloud 和 Amazon EC2)为技术提供商提供了一种强大、经济高效的方式,将新功能、功能和服务推向市场,否则将无法实现的新功能、功能和服务推向市场。Citrix 等供应商致力于在数字化转型之旅中的任何地方与客户见面,但有时候,经济高效地提供新功能的唯一方法是将其作为云服务提供。

直接迁移 - 更多资源

在 Citrix Cloud 服务诞生之前,客户已经在 AWS 上成功部署了 Citrix 虚拟化技术。在那些日子里,Citrix 将 Virtual Apps and Desktops 产品称为 XenApp 和 XenDesktop。在为此部署方案创建和发布参考体系结构和部署指南方面进行了大量工作。这些老化资源中的很大一部分细节仍然适用于今天必须继续努力的部署。

对于必须走这条路线的客户,以下发布的资源为您提供了有用的背景详细信息,您可以使用这些信息来帮助您取得成功。我们建议您在继续阅读本文档之前查看这些材料,因为我们将重点介绍自这些工程完成以来发生变化的重要设计决策:

设计决策

本节将探讨在 AWS 上架构 Citrix 虚拟化系统时需要考虑的关键设计决策。我们向下浏览 Citrix 架构设计框架的每个层,探索需要考虑的关键领域。

关于 Citrix 架构设计框架

Citrix 的 Virtual Apps and Desktops 解决方案(统称为 Citrix 虚拟化技术的产品系列)使组织能够创建、控制和管理虚拟机、交付应用程序和桌面以及实施细粒度安全策略。Citrix Virtual Apps and Desktops 解决方案为开发完整的数字工作区产品提供了统一的框架。此产品使 Citrix 用户能够独立于其设备的操作系统和界面访问应用程序和桌面。

Citrix 体系结构设计框架基于统一的标准化层模型。它提供了一个一致且易于访问的框架,用于理解大多数常见 Virtual Apps and Desktops 部署方案的技术体系结构。以下概念图中描述了这些层: 图 9:概念体系结构、Citrix Virtual Apps and Desktops 图 9:概念体系结构、Citrix Virtual Apps and Desktops。

  • 用户层 -此层定义 Citrix 环境的 用户组和位置。
  • 访问层 -此层定义了用户访问 资源的方式。
  • 控制层 -此层定义控制 Citrix 解决方案 的组件。
  • 资源层 -此层定义 Citrix 工作负载的配置以及如何将资源分配给给定用户。
  • 平台层 -此层定义虚拟机管理程序组件和云服务 提供商框架运行以托管 Citrix 工作负载的物理元素。
  • 操作层 -此层定义了支持 核心解决方案交付的工具。

用户层注意事项

在 Citrix 体系结构设计框架中,用户层描述了用户组、其位置、特定要求等。用户层可以适当地为每个用户组的环境设置总体方向。此层结合了业务优先级和用户组要求的评估标准,以便为终端节点和 Citrix Workspace 应用程序定义有效的策略。这些设计决策会影响每个用户组的灵活性和功能。

在任何平台上设计和部署 Citrix 虚拟化系统时,经过仔细评估后通过的决策和策略为客户在通过 Citrix 架构设计框架中的其他层工作时应考虑的许多其他决策奠定了基础。因此,这是彻底理解和正确的关键层面。

接入层注意事项

在 Citrix 架构设计框架中,访问层定义了用户访问 AWS 资源的方式。接入层的设计对于任何 Citrix 虚拟化系统提供的功能都至关重要。它控制用户对系统进行身份验证的方式。它还控制用户查看和启动虚拟化应用程序和桌面的方式,以及可供他们使用的应用程序和内容类型。此外,访问层控制安全代理或直接连接会话的方式和时间。

在我们之前定义的 Citrix 虚拟化系统组件 的上下文中,接入层包含以下组件和选项:

Citrix 虚拟化系统组件 提供方:
UI 服务 Citrix Workspace(由 Citrix Cloud 提供) Amazon EC2 上的 Citrix StoreFront(客户托管)
身份验证 Citrix Workspace Service(Citrix ADC/Gateway 可选) EC2 上的 Citrix StoreFront(Citrix ADC/Gateway 可选但常见)
HDX 会话代理 Citrix Gateway 服务(由 Citrix Cloud 提供) Amazon EC2 上的 Citrix ADC/Gateway VPX(客户托管)

下表包含确定要部署哪个接入层组件时的关键决策点,但选择不是二进制的。Citrix 支持各种不同的访问方法,可根据您的需求进行自定义。

UI 服务和验证注意事项

在选择如何在 AWS 上为 Citrix 虚拟化系统提供 UI 服务时,请考虑以下事项:

属性/能力 客户托管(从下载的二进制文件中安装) 云服务(通过 Citrix Cloud 提供)
能够从多个“Citrix 场”展示和启动虚拟化应用程序和桌面。 - 旧版环境(XenApp 和 XenDesktop 7.x、Citrix Virtual Apps and Desktops CR/LTSR)和 Citrix DaaS。 - 旧版环境(XenApp 和 XenDesktop 7.x、Citrix Virtual Apps and Desktops CR/LTSR)和 Citrix DaaS。有关更多详细信息,请参阅 这篇文章
能够针对不同的用例(包括身份验证要求)创建多个具有不同设置的“商店”。 -StoreFront 可以配置多个不同的应用商店,并且与 Citrix ADC/Gateway VPX 结合使用时,可以应用复杂的规则将某些设备或用户组定向到不同的应用商店。有关更多信息,请参阅 SmartAccess 如何适用于 Citrix Virtual Apps and Desktops。需要两个 StoreFront Store 的一种常见情况是,用户需要从已发布的桌面内部发布的应用程序另一种常见情况是,要求为特定用例设置仅内部存储(无 Citrix Gateway 访问),并为内部和远程访问配置另一个应用商店。有关详细信息,请参阅 配置和管理应用商店 - Workspace Service 基本上是单个应用商店,位于单个 URL 上。所有用户都使用相同的应用商店和 Workspace 设置。身份验证要求只设置一次,并适用于 Workspace 租户的所有用户。
能够使用 Citrix Secure Private Access 服务在 SaaS 和 Web 应用程序中枚举、启动和单点登录,同时利用 Web 过滤和增强的安全控制策略以及高级的 ML 增强型分析。 -需要使用 Citrix Workspace。 -使用 Citrix Gateway 服务,只需在 Citrix Cloud 控制台中“开启”集成一样简单。SaaS 应用程序只需通过基于 Web 的向导进行定义,管理员可以使用大量预定义应用程序列表作为起点。
能够通过 Citrix Workspace 应用程序和 Web 浏览器 (HTML) 访问/索引/搜索 Citrix Files(以前称为 ShareFile)内容。 -StoreFront 无法将基于文件的内容集成到 Workspace 应用程序或 StoreFront HTML UI 中。 -默认情况下启用,具体取决于对 Citrix Cloud 的订阅。将来自各种来源(包括本地文件共享)的用户基于文件的内容引入 Workspace UI,包括 HTML 和 Workspace 应用程序。
能够使用 Citrix Remote PC Access 功能呈现和启动与物理桌面的连接。 -无论是由 CVAD 还是由 DaaS 处理代理业务。 -无论是由 CVAD 还是由 DaaS 处理代理业务。
对于多站点和灾难恢复用例,能够使用区域首选项和故障切换精确控制会话启动行为。 -使用 Citrix Zone 跨多个 AWS 区域和可用区进行部署是在停机情况下扩展东西部和限制受影响用户群的好方法,并允许区域首选项和无缝故障切换到主区域。请参阅 CVAD 区域文档 部分 - Workspace Service 不包括功能齐全的区域首选项和故障切换功能,但可以使用主区域为用户或应用程序实现类似的效果。有关详细信息,请参阅 Citrix DaaS 区域文档
当资源位置/区域与 Citrix Cloud 之间的连接失败或 Citrix Delivery Controller 下的数据库不可用时,能够代理新的和现有的连接。 - 使用 Cloud Connector 和 Delivery Controller 上的本地主机缓存功能,为这两种潜在的故障情况提供弹性。对于具有广泛弹性要求的环境,Citrix 建议将 StoreFront 与本地主机缓存部署。有关详细信息,请参阅 本地主机缓存 (CVAD) -在 Citrix Cloud 通信失败时,Cloud Connector使用本地主机缓存功能来代理资源连接。这需要资源位置可访问的被动 StoreFront 服务器来处理故障转移方案。有关详细信息,请参阅 本地主机缓存 (DaaS)
能够配置和利用自定义的“虚荣 URL”供最终用户使用。 -客户可以完全控制使用并向用户提供的 URL 和证书。通过公共网络进入是否需要 SSL 证书、DNS 别名创建/管理和 Citrix ADC/Gateway 实例。 部分 -尽管客户可以 配置自己的自定义前缀 (customername.cloud.com),但所有工作区都是从 cloud.com 域交付的。
能够通过 Citrix ADC/Gateway VPX 或 Citrix Gateway 服务智能地将网络上用户直接路由到 VDA 和网外用户。 -StoreFront 使用管理员定义的“信标”,Citrix Workspace 应用程序使用该信标来确定用户是在网络还是脱离网络。 即将推出 -此功能预计将在 Citrix Workspace 上提供,网络定位服务一旦正式推出。有关更多信息,请参阅 网络定位服务预览版
能够将 Citrix Gateway 服务用于简单、预配置的 HDX 会话代理服务。 -如果需要在网外访问 Citrix 虚拟化应用程序(在 99% 的部署中),StoreFront 需要使用客户托管的 Citrix ADC/Gateway 来实现 HDX 会话代理功能。 -默认情况下,已为所有新 Citrix Workspace 租户配置和启用此功能。
包括通过 Active Directory 和 TOTP 进行的内置多重身份验证 -Citrix ADC 包括内置的 TOTP 功能,可用于第三方身份验证器,还支持第三方应用程序/设备/服务。 -Citrix Workspace 包括此功能,包括自助 OTP 设备恢复和向最终用户发送自动推送通知。支持 Citrix 和第三方身份验证器应用程序。
SSO 功能(虚拟化、SaaS 和 Web 应用程序) 部分 -SSO 到开箱即用的虚拟化应用程序。 -SSO 到 Citrix Workspace 本身提供的虚拟化、SaaS 和 Web 应用程序。网关服务和 Secure Private Access 包括 Web 过滤和策略控制。
能够从多种预定义的身份验证方法中进行选择,并将所选方法应用于系统上的所有用户。 的-有更多的选择和灵活性。Citrix StoreFront 允许您创建多个应用商店,身份验证方法是基于每个应用商店进行配置的。每个应用商店可以配置一个或多个选项,管理员可以从 Active Directory 用户名/密码、SAML 身份验证、域直通、智能卡、HTTP Basic 和 Citrix Gateway 直通选项中进行选择。还可以启用自助服务密码重置。有关详细信息 ,请参阅配置身份验证服务 。当 Citrix ADC/Gateway(客户托管)部署并与 StoreFront 一起使用时,可以配置各种身份验证选项,以及额外的逻辑,以便根据需要将用户定向到特定应用商店,以支持几乎任何使用案例。 如果不同的用例需要复杂的集成和不同的身份验证方法,则建议使用 Citrix StoreFront 和 Citrix ADC/Gateway。 -目前,Active Directory、Azure AD、Active Directory + TOTP 令牌、Azure AD 和 Citrix Gateway 目前都支持选项。Okta 和 Google Cloud ID 选项已进入预览版或即将推出。有关更多信息,请参阅 保护工作区 。除 Citrix Gateway 之外,您的身份验证选择适用于所有用户和通过 Citrix Workspace 租户 /URL 提供的所有服务。使用 Citrix Gateway 选项,客户可以支持各种身份验证选项(RADIUS MFA、智能卡、联合身份验证、条件访问策略等),并将其灵活应用于不同的用户组和用例。有关更多信息,请参阅 将本地 Citrix Gateway 作为身份提供商连接到 Citrix Cloud
使用联合身份提供程序启动虚拟化 Windows 应用程序/桌面时,能够 SSO 访问 VDA 上的会话 -Citrix 联合身份验证服务 (FAS) 在使用联合身份提供程序(如 SAML(安全断言标记语言)时启用 VDA 的 SSO。 即将推出 -通过将 Citrix 联合身份验证服务 (FAS) 与 Citrix Workspace 配合使用。截至撰写本文时,此功能处于预览中。有关详细信息,请参阅使用 Citrix FAS 为 Workspace 启用 SSO

HDX 会话代理注意事项

在选择如何为 AWS 上的 Citrix 虚拟化系统提供 HDX 会话代理功能时,请考虑以下事项:

属性/能力 客户托管(AWS 上的 Citrix ADC/Gateway VPX) 云服务(Citrix Cloud 提供的Citrix Gateway 服务
简单的预配置服务,提供无管理开销的 HDX 代理 -作为客户管理的组件,这些设备需要许可、安装、配置和维护。 - Citrix Gateway 服务 是一个完整的 HDX 代理解决方案,由 Citrix 管理,作为云服务提供。
能够使用 Citrix HDX 的基于 EDT (UDP) 的传输协议。有关详细信息,请参阅 自适应传输如何配置 HDX Enlightened Data Transport 协议 -此功能可优化来自高延迟站点的流量,可用于客户托管的 ADC/Gateway 实例。 尚未 -截至撰写本文时,此功能已处于预览中。网关服务目前仅支持基于 TCP 的 VDA 连接。
能够为客户托管的基础架构提供负载平衡、运行状况检查、SSL 卸载以及各种其他高级网络和应用程序交付服务。 -Citrix ADC/Gateway VPX 设备提供了复杂、业界领先的功能,其中许多功能只需将适当类型的许可证应用于设备即可启用。 -对于 Citrix CVAD 和 Citrix DaaS 代理环境,网关服务提供对在客户的 AWS 或本地环境中运行的虚拟化应用程序的简单、安全的访问。
支持客户在数据中心、区域和区域之间可配置的全局服务器负载平衡 (GSLB)。 -可以为 GSLB 设置客户管理的 Citrix ADC/Gateway 实例,尽管客户负责设置和管理。 是-… 但是并没有真正的需要:Gateway S ervice在全球范围内使用14个或更多POP以及集成的GSLB ,以确保用户无论身在何处都能获得最佳的会话性能。
需要使用 Citrix Workspace UI 进行 HDX 会话演示和启动。 -可以将客户托管的 Citrix ADC/Gateway VPX 实例与 Workspace UI 和 StoreFront 使用。 -网关服务只能通过适用于 HDX 代理的 Citrix Workspace UI 进行配置-它不为 Citrix StoreFront 提供 HDX 代理功能。
需要 Cloud Connector 实例上的额外资源才能将会话代理到安全网络。 -虽然Cloud Connector为客户托管的 Citrix ADC/Gateway VPX 实例执行 STA 票证验证,但不需要额外的资源,因为所有 HDX 会话都是通过 VPX 代理的。 -今天,网关服务使用从 Cloud Connector 实例到 Citrix Cloud 的长期出站 TCP 连接将 HDX 流量代理回私有网络。在调整和配置 Cloud Connector 实例时,这需要额外的资源考虑。有关更多详细信息,请参阅 这篇文章注意 -一旦网关服务和 VDA 可以使用 Rendezvous 协议/功能,此要求对于大多数使用案例来说就没有意义了。这需要 Citrix VDA 1912 或更高版本。
能够与 Citrix Cloud Government 租户一起使用。 -支持内部部署和基于 AWS EC2 的 ADC/Gateway/StoreFront 部署。 -Citrix Workspace 可在 Citrix Cloud Government 中使用。
能够在没有出站 Internet 连接的情况下支持空气间隙的 AWS 云/环境。 -本地实例和基于 AWS EC2 的实例均支持由客户管理的 ADC/Gateway(和 StoreFront)部署。 - 气隙 AWS 环境无权访问 Citrix Cloud 或 Citrix Cloud Government,因此网关服务和 Workspace Service 目前不可用。

摘要、建议和领先实践

现在,我们已经回顾了一些属性/特性/功能,这些属性/特性/功能有助于推动接入层子系统的客户托管与云服务决策,接下来让我们结合我们先前定义的 部署模型 来研究最高级别的决策。

接入层:Greenfield /仅云部署

由于绿色领域或仅云部署模式全面使用云服务,因此 AWS 对 Citrix 虚拟化系统设计的具体影响很简单:没有任何影响。 无需在 AWS 上构建或配置任何内容,因为 UI 和 HDX 代理服务所需的所有内容都已为您提供,配置并可以“开箱即用”。

Citrix 部署的接入层是向用户交付虚拟应用程序和桌面的关键要求。如果接入点无法访问或发生故障,则用户将无法访问其资源。网络设计和实施可能会很复杂,但是使用 Citrix Gateway 服务和 Citrix Workspace,冗余、故障转移、维护和全球存在都是软件包的一部分-无需网络知识。使用 Citrix Gateway 服务和 Citrix Workspace 可以减少您的基础设施足迹很大。通过将接入层移动到云服务模型,用户可以从世界任何地方安全地访问网络资源。这种方法需要的部署和维护工作最少,因此,如果您想快速启动和运行、有限的 IT 人员,或者基础架构不是您的重点,这是一个不错的选择。随着所有预先配置的部署模式,这种部署模式是最不可定制的,但是对于部署简单、安全、功能齐全且全局可访问的系统,将 Citrix Workspace 和 Gateway Service 用于接入层是必不可少的。

接入层:混合部署

使用混合部署模型,您将构建/管理一些 Citrix 虚拟化系统组件,否则根据定义,这是一个绿色领域或仅限云部署。使用混合模式,您可能正在 AWS 甚至本地部署 Citrix ADC/Gateway VPX,根据您的要求,您可能还在 AWS 或本地部署 Citrix StoreFront。在本地网关和身份解决方案上进行了大量投资的客户可以从使用 Citrix Gateway 作为 Workspace 的身份提供商的能力中受益。

此部署模型常用于以安全为中心的部署、使用当前本地基础架构(ADC 或 StoreFront)的部署以及现有客户托管数据中心的 DR/ 故障转移站点。此模型的关键考虑因素之一是尽可能靠近用户、资源和接入点。 选择在本地资源位置附近部署接入层的 AWS 区域。尽可能让 ADC 和 StoreFront 服务器尽可能靠近彼此。这是事情可能变得棘手的地方。在设计混合部署时,请考虑 Citrix Virtual Apps and Desktops 的启动顺序 ,特别要注意所有流量都通过 Citrix ADC 路由。

借助 Citrix ADC/Gateway 和 StoreFront 在 AWS 中作为基于 EC2 的实例,自定义的潜力也更大。除了多个 StoreFront 应用商店、多因素身份验证和各种业界领先的 ADC 功能之外,混合部署还可以使用原生 AWS 服务,如关系数据库服务 (RDS) 和 AWS 目录服务。混合部署有助于实现更渐进的云过渡,并为在此过程中对架构进行调整留出空间,而不是提升和转移方法。

与纯绿地/云模式相比,混合方法确实需要更高级别的专业知识和更长的部署准备时间,但可以作为传统客户管理/本地部署和仅云状态之间的稳固过渡状态。

接入层:直接迁移部署

使用传统的直接迁移部署模型,您可以在 AWS 上部署 Citrix ADC/Gateway VPX 和 Citrix StoreFront,或者可能为相同目的重复使用这些技术的现有本地部署。对于使用现有本地 Citrix 虚拟化环境的客户而言,此类部署往往具有最短的准备时间,而且从操作和维护角度来看也是最简单的过渡。由于 Citrix 基础架构在很大程度上保持不变,因此具有管理本地环境经验的员工在直接迁移部署模式下可以缩短加速时间。具体而言,对于接入层来说,此方法很简单,允许进行许多自定义操作。对于进入云的现有部署或新的或空气缺口的 AWS 区域而言,这种直接迁移是一个很好的第一步,但可能会阻碍将来采用云转发架构。

AWS 上的 Citrix ADC/Gateway VPX

在 AWS 上部署 Citrix ADC/Gateway 与本地部署 Citrix ADC/Gateway 不同,尽管最终您是自己管理它们。 幸运的是,在 AWS 上部署 Citrix ADC/Gateway 已有全面的文档记录,因此我们建议您在巩固设计并开始实施之前查看以下资源:

虽然 AWS 上的 Citrix ADC/Gateway VPX 架构可能存在变体,但下图(来自 适用于 Web 应用程序的 Citrix ADC 快速入门部署指南)描述了由快速入门模板(使用默认子网/CIDR 块)部署的多可用区 Citrix HA 对部署:

图 10:概念架构、AWS 上的 Citrix ADC/Gateway VPX 具有跨可用区 的高可用性图 10:概念架构、AWS 上的 Citrix ADC/Gateway VPX 跨可用区的高可用性。

正如 Citrix Docs 上的 AWS 上的 Citrix ADC VPX 中所讨论的那样,有两个主要的部署选项可供选择。具体如下:

  • 独立:Citrix ADC/Gateway 的单个实例可以作为单独的实体进行部署和管理。这通常用于不需要高可用性的小 规模或 POC 部署。

  • 高可用性:这是生产 环境中最常部署的模型:可以在 AWS 上使用本机 Citrix HA 模式部署对 Citrix ADC/Gateway VPX 实例。对于较旧的固件版本,该对部署在同一 AWS 可用区中。从 Citrix ADC 12.1 固件开始 ,可以跨可用区 (AZ) 部署高可用性 VPX 设备对。AWS 的高可用性如何运作解释了在 同一可用区内和跨可用区部署一对 ADC 的区别。我们在本节后面将更深入地研究此选项。

尽管 Citrix ADC VPX 通常支持单个、双或多个 NIC 部署类型,但 Citrix 建议在 AWS 上部署时为每个 ADC 至少使用三个子网,每个子网中都有一个网络接口以实现最佳吞吐量和数据分离。在部署到支持 Citrix Virtual Apps and Desktops 时,NSIP 通常附加到“私有 Citrix 基础架构子网”,SNIP 连接到“私有 Citrix VDA 子网”,Citrix Gateway VIP 连接到公有子网。下面简化的概念图描述了此配置。它显示了单个可用区中的单个 VPX 实例-对于高可用性配置,此设计模式将被复制(可能在第二个可用区中):

图 11:用于 CVAD/DaaS 部署的 Citrix ADC VPX 实例接口映射 图 11:用于 CVAD/DaaS 部署的 Citrix ADC VPX 实例接口映射。

跨可用区域的 ADC 高可用性

如前所述,这是 Citrix 虚拟化系统最常见的部署模型。此模型使用通过使用 Citrix ADC 的本机 HA(主动/被动)功能或 Citrix ADC 的本机全球服务负载平衡 (GSLB) 和 IPSet 功能的组合,跨可用区部署的一对 Citrix ADC VPX。 后一种选项(在 2020 年初开始可行)允许跨可用区进行主动/主动配置,并通过允许 ADC 充当权威 DNS 源来运行。这种新的选项/架构预计将在公共云部署中受欢迎,因此我们在此将重点关注这一点。

云负载平衡器的基于域的服务允许自动发现动态云服务。通过在主动-主动配置中跨多个可用区部署 Citrix ADC,您可以使用不同可用区中的云资源来优化高可用性/灾难恢复。每个可用区都可以在熟悉的 Pod 基础架构中包含云资源,以便轻松管理更新、修补和扩展扩展。有关在 AWS 可用区之间设置 GSLB 的详细信息,请参阅 Citrix 文档

图 12:多可用区高可用区高可用性部署中高可用性故障转移前后的流量图 12:多可用区 高可用区高可用性部署中高可用性故障转移之前和之后的流量。

在上图中,我们可以看到每个 ADC 都有不同的网关虚拟 IP (VIP)。这是 独立网络配置 (INC)的特征。 当 HA 对中的 VPX 驻留在不同的可用区中时,辅助 ADC 必须具有 INC,因为它们无法共享映射的 IP 地址、虚拟局域网或网络路由。在此配置中,每个 ADC 的 NSIP 都不同,而 Snip 和负载平衡 VIP 使用 名为 IPset 的特殊的 Citrix ADC 功能,即多 IP 虚拟服务器,该功能可用于不同子网中的客户端连接到同一组服务器。使用 IPset,您可以将私有 IP 关联到每个主实例和辅助实例。然后,可以将公有 IP 映射到该对中的主 ADC。在故障转移的情况下,公有 IP 映射会动态更改为新的主 IP。对于 AWS 中的 GSLB 部署,服务 IP 可以是 IPv4 和 IPv6 流量的 IPset 的一部分。

有关将远程节点添加到 ADC 以创建基于 INC 的高可用性对的更多信息,请参阅 Citrix 文档

AWS 上的 Citrix StoreFront

在 AWS 上部署 Citrix StoreFront 与在本地部署没有太大区别,最后,您还可以自己管理 StoreFront 的所有组件。请参阅 规划 StoreFront 部署 ,了解适用于所有部署(包括 AWS 上的 StoreFront)的一般注意事项。主要区别在于,您通常跨多个 AWS 可用区在 StoreFront 服务器组中部署多个 StoreFront 实例。需要注意的是,通过此设计启用的功能 取决于可用区之间的延迟。根据 计划您的 StoreFront 部署/可扩展性,只有在服务器组中服务器之间的链接延迟小于 40 毫秒(禁用订阅)或小于 3 毫秒(启用了订阅)的情况下,才支持 StoreFront 服务器组部署。 确保测量计划托管 StoreFront 的所有可用区中实例之间的延迟,并相应地启用/禁用订阅。

我们已经在本文档前面的 UI 服务和身份验证注意事项 表中提到了这一点,但值得再次指出: 对于具有广泛弹性要求的 Citrix DaaS 环境,Citrix 强烈建议使用 StoreFront 实施以充分受益从本地主机缓存功能 (在 CVAD 和 DaaS 会话代理基础结构类型中可用)。对于 CVAD,如果数据库中断,这将提供弹性。 对于 DaaS,此架构可在 Cloud Connector 无法访问 Citrix Cloud 时提供弹性。无论哪种情况,断开连接的用户在停机情况下仍然能够连接到新的和现有的会话。有关本地主机缓存激活的更多详细信息、限制和影响,请参阅 本地主机缓存 (DaaS)本地主机缓存 (CVAD)

在我们讨论恢复能力的主题时,Citrix 还建议您的 StoreFront 实施跨越多个可用区(如果 AWS 区域包含多个可用区),但请记住将 ADC 设计考虑在内。 Citrix ADC 通常在 StoreFront 实例之前使用,以提供负载平衡和额外的服务弹性。

通过利用 Citrix 区域,可以通过将卫星区域分布在具有单个站点的 VPC 中的两个或多个可用区来构建 StoreFront 冗余。使用区域是让资源尽可能靠近用户并且具有高可用性的好方法。从属区域包含 StoreFront 服务器、Delivery Controller 和应用程序/桌面资源,在主区域中保留完整的基础架构设置,包括许可证服务器和 SQL。 这允许 StoreFront Web UI 的可扩展性和区域创建/销毁可以协调。保持区域的缩小将有助于实现最佳的东西扩展性,并在停机时减少影响。

StoreFront on AWS 是完全可定制的,包括精选应用程序组、启动页、着色和徽标,并且可以根据您的特定需求以最佳方式安排应用程序和桌面。StoreFront on AWS 还需要保持知识渊博的管理和工程设计,但可以提供强大的 Web UI,尤其是与 Citrix ADC 集成时。

资源层注意事项

资源层设计侧重于个性化、应用程序和图像设计。资源层是用户与桌面和应用程序进行交互的地方。在 AWS 上部署 Citrix 虚拟化系统时,需要记住的关键事项(除了我们在此处不介绍的所有“正常”内容之外):

  • CIFS 存储和数据复制 -无论用于管理用户个性化设置(用户的 Windows 配置文件和重定向文件夹)的工具 如何,您都必须拥有 Windows 文件共享才能存储它们。如果您在多个区域中有 VDA(用户可以在多个区域访问应用程序/桌面),那么您还必须处理数据复制问题。许多应用程序还使用 Windows 文件共享,因此 CIFS 存储和数据复制对于这些方面也很重要。
  • 映像设计 -Citrix App Layering 和 Citrix Provisioning 服务 (PVS) 目前不支持 Amazon EC2-在 AWS 中托管资源位置的客户使用 Machine Creation Services 来创建、管理和更新 VDA 队列。

CIFS 存储和数据复制

AWS 上的大多数 Citrix 虚拟化系统都需要至少对 Windows 兼容文件共享的基本访问权限才能保留用户设置、用户数据和应用程序数据。当这些共享不可用时,用户体验和应用程序功能将受到影响,因此,务必确保您选择提供 Windows 兼容文件共享的任何解决方案都具有高可用性并定期备份数据。

对于多站点部署,可能还需要可靠且高性能的数据复制,以满足可用性、RPO 和 RTO 需求。对于用户可以连接到 2 个或更多区域的桌面/应用程序的环境来说尤其如此,并且应用程序数据/用户设置必须在应用程序/桌面运行的区域可用。以下部分介绍了在 AWS 上提供 CIFS 存储和数据复制服务时需要考虑的一些解决方案。

虽然存在提供 Windows 文件共享的非 Windows 解决方案,但大多数这些解决方案无法提供 Windows 桌面或应用程序(例如在 Windows 上运行的 Microsoft Outlook)中搜索功能所需的索引功能。因此,大多数客户转向基于 Windows 的文件服务器解决方案,至少用于存储用户配置文件和持久应用程序数据。幸运的是,在 AWS 上运行 Citrix 虚拟化系统时,客户托管和云服务选项都可以使用。

客户托管:Amazon EC2 上的 Windows 文件服务器

许多客户考虑在 AWS 上提供 Windows 兼容文件服务的第一个解决方案是在 EC2 上构建自己的 Windows 文件服务器,以便为 AWS 上的每个资源位置提供服务由于各种不同类型的应用程序和工作负载都需要 Windows 文件服务器,因此许多 IT 商店可能会倾向于构建和管理自己的文件服务器,因为这是他们知道如何做的事情。在最基本的层面上,客户可以旋转一个或多个 Windows EC2 实例,附加额外的 Amazon Elastic Block Store (EBS) 卷,将实例加入其 Active Directory,然后忙于配置和设置 Windows 文件服务。

正如您可能想象的那样,此选项为客户提供了最大的控制和灵活性。虽然这对某些类型的客户和某些垂直行业非常有吸引力,但也需要付出代价:规模、扩展、构建、管理、修补、保护和维护 Windows 操作系统的所有内容的责任。选择这条路线的客户还应确保这些文件服务器具有高度可用性。 这通常是在多个可用区中使用文件服务器和使用 Windows DFS-N/DFS-R 来实现的,但如果您不小心,很容易以不受支持的配置(根据 Microsoft)来实现。

*注意:考虑使用此选项的 客户应查看 Microsoft 关于将 DFS-R 和 DFS-N 用于漫游配置文件共享和文件夹重定向共享的支持声明 。* 由于 Citrix 虚拟化系统将在 AWS 上运行,因此还有一点需要考虑:新的部署或迁移事件可能会提供一个绝佳的机会,让您可以评估是否使用云服务来实现 Windows 文件服务,而不是构建自己的云服务。幸运的是,Amazon 有一些值得考虑的云服务选项。我们现在谈谈其中的一些。

云服务:适用于 Windows 文件服务器的 Amazon FSx

适用于 Windows 文件服务器的 Amazon FSx 是一项云服务,客户可以在 AWS 上使用。适用于 Windows 文件服务器的 FSx 提供了完全托管的本机 Windows 文件系统和基于 SSD 的存储,具有一致的亚毫秒级性能。由于 FSx 是基于 Windows Server 构建的,因此它提供了一个完全原生、Windows 兼容的文件系统,为 AWS 上的 Citrix 虚拟化系统提供存储和保护。适用于 Windows 文件服务器的 FSx 也经过了 Citrix Ready 验证,这意味着此 AWS 支持的解决方案已经由 Citrix 验证与 Citrix Virtual Apps and Desktops 兼容。尽管 Citrix 不正式支持该服务,但该服务基本上是Microsoft Windows 本机文件服务器-它只是由 AWS 而不是客户管理。有关更多信息,请参阅 Citrix Ready 上的 Windows 文件服务器版 Amazon FSX

对于 IT 团队来说,这是一个很好的选择,可以消除围绕部署和管理存储的许多平常或低价值的任务。最重要的是,使用 FSx 可以减轻安全性、数据保护/备份、法规遵从性、软件更新/修补任务以及对存储基础架构的监视以确保其满足所需的服务级别。IT 团队可以将整个 FSx 文件服务视为单个操作平台,而不是管理 Windows 操作系统文件服务器、存储、网络等。此外,FSx 支持其已使用的所有常见管理工具,例如 Active Directory (AD) 集成、Windows DFS 命名空间、DFS 复制等。

您创建的每个 FSx 托管文件系统基本上都变成了特定可用区域中的高可用性和持久性文件服务器。为了维护 Citrix 虚拟化系统,客户应确保这些“文件系统”具有高可用性。这可以通过在多个可用区中配置 FSx 托管文件系统,然后使用 Windows DFS-N/DFS-R 创建高可用性 Windows 文件共享来实现,尽管如果您不小心,很容易以不受支持的配置(根据Microsoft )结束。

*注意:由 于 FSx 是 Windows 文件服务器,因此考虑使用此选项的客户应查看 Microsoft 关于将 DFS-R 和 DFS-N 用于漫游配置文件共享和文件夹重定向共享的支持声明 。*

更多云服务选项

除了 Amazon 的第一方托管 Windows 文件服务外,AWS 还支持更广泛且功能丰富的选项,其中一些选项与传统的本地存储技术相集成。虽然这些其他选项不在本文档的范围之内,但有许多选项可供选择。开始探索选项的好地方是在 AWS Marketplace上。这些类型的解决方案尤其适用于需要可靠和弹性数据复制的更复杂、多区域的使用案例。

CIFS 存储和数据复制:摘要和结论

客户可以管理自己的高可用性 DFS 文件共享、作为 AWS 服务 (FSx) 受益以节省管理工作量,或使用第三方存储设备解决方案在本地环境中进行扩展。Citrix 建议客户分析每种方法的优缺点,以确定适合他们的解决方案。

图像设计和管理

在 AWS 上的 Citrix 虚拟化系统中,应用程序和桌面通过称为“VDA”的 EC2 实例(以 Citrix 的虚拟交付代理软件命名,该软件安装在包含 Citrix 虚拟化系统提供的应用程序的 Windows 或 Linux 实例中)交付。在“计算机目录”中配置和维护一组相同的 VDA,这是一种通过会话代理和管理子系统(DaaS 和 CVAD)定义和维护的管理结构。创建、调整和管理这些实例至关重要,因为许多系统都有大量 VDA,而 VDA 中的软件堆栈随着修补程序、Service Pack 和软件更新的应用而频繁更改。我们将在本节中讨论一些更高级别的注意事项。

VDA 预配和映像管理

在 AWS EC2 上,Citrix 虚拟化系统使用 Citrix 的 Machine Creation Services (MCS) 配置技术进行 VDA 部署和映像管理。MCS 利用 EC2 上的 IAM 服务帐户来协调控制过程(将模板虚拟机系统磁盘的快照转换为通用 AMI)、克隆过程(基于从模板虚拟机快照创建的 AMI 创建和管理 VDA 实例队列)、自动扩展传递分组、更新已部署的映像等。我们将在本文档的 控制层注意事项 部分中更详细地讨论 AWS 上的 MCS。

注意: 已在本地 环境中使用 MCS 的客户可能会注意到在 AWS 中预置计算机时,他们可以使用的选项之间存在一些差异。EC2 上的 MCS 托管 VDA 实例附加了两个磁盘:系统磁盘(在母带控制过程中创建的模板映像 AMI 的读/写副本)和 1GB 个性化磁盘。根据配置的计算机目录类型和托管连接选项,系统磁盘(有时还有虚拟机实例)将在关闭时删除,并在“开机”时(对于池或共享目录)重新创建系统磁盘,或保留它们(对于持久性目录类型)。有关更多信息,请参阅 CTX234562

交付和持久性模型

选择正确的交付模式至关重要,其影响不仅仅是成本。Citrix 虚拟化技术支持三种主要交付模式,可混合和匹配,并组合使用以支持许多不同的使用案例。三种交付模式是:

  • 托管共享: 尽管 Linux 实例可以为兼容的应用程序提供相同的功能,但托管共享模型通常使用安装了 RDSH 角色的 Windows Server 操作系统。使用此模型,单个 VDA 实例可以同时支持多个用户,每个用户都运行完整桌面或连接到一个或多个已发布的应用程序。在安装了桌面体验和相关组件的情况下使用 Windows Server OS/RDSH 时,桌面和应用程序看起来和感觉就像在 Windows 桌面操作系统上运行一样。由于给定实例上的每个用户都共享操作系统实例,因此管理员通常会在托管共享实例上预安装和配置混合应用程序,而用户没有操作系统的本地管理员权限。 托管共享实例也可以在共享基础设施上运行,并且可以使用按需和预留实例定价模型进行使用。 管理员通常会部署一组实例来支持托管共享模型,Citrix 代理子系统的客户托管和云服务类型都提供了复杂的负载平衡功能,以确保每个用户体验足够的性能。 托管共享实例还可以在 AWS 上使用 GPU 支持的实例类型来提高可受益于 GPU 的图形密集型工作负载的性能,尽管 GPU 供应商可能需要额外的许可证。Windows Server 操作系统和 RDS CAL 许可证都可以在Microsoft 的 SPLA 许可模式下“租用”,但客户可以通过使用 Linux 作为操作系统来避免这些额外费用。这种模式是在 AWS 上运行的最具成本效益的模式。
  • 服务器 VDI:“服务器 VDI”(虚拟桌面基础架构)模型还使用 Windows Server 操作系统,安装了桌面体验和相关组件后,用户看起来和感觉就像 Windows 桌面操作系统一样。RDSH 角色未与此模型一起安装,因此一个实例一次支持一个用户,有时为用户提供服务器操作系统的提升权限,以便他们可以安装自己的应用程序。与托管共享实例一样,服务器 VDI 实例也可以在共享基础架构上运行,可以使用按需和预留实例定价模式使用,可以使用 GPU 支持的实例类型,并且可以在Microsoft 的 SPLA 许可模式下“租用”Microsoft 操作系统和 RDS CAL。鉴于目前可用的工具,99% 的 Windows 应用程序可以安装和运行在 Windows Server 操作系统上,尽管有时软件供应商不明确支持他们在 Windows Server 上的应用程序,但是大多数 Windows 应用程序在 Windows Server 上运行的情况都像在 Windows 桌面操作系统上一样运行。同样值得注意的是,服务器 VDI 实例还可以在 AWS 上使用 GPU 支持的实例类型来提高可受益于 GPU 的图形密集型工作负载的性能,尽管 GPU 供应商可能需要其他许可证。这是在 AWS 上运行的第二个最具成本效益的交付模式。
  • 客户端 VDI: 客户端 VDI 交付模型通常使用 Windows 10 或 Windows 7 等 Windows 桌面操作系统,尽管也可以使用受支持的 Linux 操作系统版本。客户端 VDI 是 1:1 模型,这意味着每个唯一用户都需要自己的操作系统实例。新接受 Citrix 虚拟化技术的客户通常会加入这些类型的项目,要求客户端 VDI,尽管可以使用更经济高效的模型。他们的语言也可能受到其他虚拟化供应商的影响,这些供应商的技术堆栈不支持托管共享或服务器 VDI 部署模型。客户端 VDI 模型虽然表面上看起来“简单”,但是越深入,尽管使用 Linux 作为操作系统可以避免大部分复杂性。这种复杂问题大部分是由Microsoft 对 Windows 桌面操作系统的许可要求驱动的,这与 Windows Server 不同,Microsoft 的 SPLA 许可计划无法获得。因此,客户必须自备这些产品的许可证。 另外-基于 Windows 桌面的客户端 VDI 实例无法在共享基础架构上运行。这意味着客户端 VDI 实例必须在 AWS 专用实例或 AWS 专用主机上运行。这大大增加了管理所需基础架构的成本和复杂性,降低了灵活性和成本控制选项,并且很快就变得昂贵。正如您所期望的那样,客户端 VDI 实例还可以在 AWS 上使用 GPU 支持的实例类型来提高图形密集型工作负载的性能,尽管 GPU 供应商可能需要更多许可证。客户端 VDI 是在 AWS 上运行的最昂贵的交付模式。 对于这两种 VDI 模型,另一个重要的考虑因素是持久性模型。VDI 实例可以随机分配给没有持久性的用户(集中),或者用户可以分配持久保留且个性化(专用)的计算机。随着时间的推移,池实例可以更容易管理,因为给定池中的所有实例都是相同的。 Citrix 的 MCS 只需单击几下即可更新连接到池实例的系统磁盘,容量/成本管理更有效,因为空闲的实例池可以为许多用户提供服务。池实例比专用实例的灵活性稍低,因为最终用户对池实例的更改通常不会在重启之间持续存在,尽管 Citrix App Layering 的用户层或 CVAD 1912 中发布的个性化层等技术可用于将对用户体验的影响降至最低。从成本角度来看,专用实例也可能更难管理,因为通常很难预测用户何时登录,用户必须在启动实例时等待,或者管理员必须在每个用户都要登录的时间窗内保持运行。

尽管我们之前已经提到过,但为了清楚起见,我们将在此再次提及:只要一个或多个应用程序在 Linux 上运行,各种类型的 Linux 就可以在 Citrix 虚拟化系统中使用。Citrix 的虚拟化技术支持托管共享和 VDI 交付模型、持久模型和池模型以及 GPU 支持的实例类型。用户和管理员的体验与基于 Windows 的实例不同,但是基于 Linux 的 VDA 由于不需要 Microsoft 许可证,因此通常运行成本要低得多。

最后,让我们重新审视 GPU 加速的考虑。所有三种交付模式(适用于 Linux 和 Windows)都可以在 AWS 上使用 NVIDIA 加速 GPU 实例。G 系列实例可用于图形加速使用案例,但对于一般用途来说尚不具有商业可行性。请注意,Citrix 目前不支持 AWS Elastic GPU,但是由于 Elastic GPU 仅适用于 OpenGL,因此它对企业中典型图形工作负载的影响微乎其微。

那么-您使用哪种交付模式?值得注意的是,您可以在同一系统中混合搭配交付模型,以满足不同用户组或使用案例的需求。从基础架构角度看,最具成本效益的交付模式是托管-共享。 服务器操作系统与多用户并发的组合非常高效,每台虚拟机的用户数量可以根据用户类型(例如,任务工作人员与知识工作者与高级用户)相应地调整大小,以确保良好的体验。对于用户和应用需要托管共享不满足的额外功能的情况,VDI 是您的选择。应首先评估服务器 VDI:运行适用于 Windows 工作负载的 Windows 10 VDI 更具成本效益,而且服务器 VDI 可以提供外观和感觉类似于 Windows 10 的桌面。此外,服务器 VDI 没有使用专用实例/主机的Microsoft 最终用户许可协议的要求-客户端 VDI(部署 Windows 10 或有时还有 Windows 7)。对于 AWS 上基于 Windows 的工作负载,客户端 VDI 应被视为最后的手段,并且只有在托管共享模型和服务器 VDI 交付模式不可能实现时才部署。

为了帮助制定决策,以下诊断树将 托管共享桌面(服务器操作系统多用户桌面)与 VDI 桌面进行了比较。 该树没有明确区分客户端 VDI 和服务器 VDI 模型。当使用案例表明 VDI 是适合您的工作负载的交付模式时,应尽可能考虑在 AWS 上运行 Server VDI,因为它的成本效益和更易于管理。

AWS 实例账单模型

一旦您决定使用哪种交付模式(托管共享、服务器 VDI 或客户端 VDI),下一步是规划按小时按需计费模式或预留计费模式。理想情况下,使用按需计费模式按小时为尽可能多的 VDA 付费,并使用 Citrix AutoScale 功能控制成本。通过使用 Citrix AutoScale(DaaS 云服务代理子系统独有的功能),虚拟机可以根据需要开机,并预计会出现高峰时段。但是,在非高峰时段,虚拟机将关闭,因此重要的是使用托管共享模型整合负载,对于所有模型,确保用户保存工作并理想情况下从会话中优雅地注销。 预留实例容量可用于基础设施组件,如Cloud Connector(全天候保持 24 小时)和预定数量的 VDA(例如,峰值的 10%)。与按需定价相比,预留实例除了提供大幅折扣外,在特定可用区中使用时,预留实例还提供容量预留。

VDA 实例规模调整和成本管理

在 AWS 上运行一系列 VDA 时,为您的不同工作负载 (VDA) 选择合适的实例类型是一项关键决策,同时考虑到性能、可管理性和成本考虑因素。选择太小的实例,性能可能会受到影响。选择太大的实例,您需要为未使用的资源付费。选择正确的实例类型最终是一种平衡行为,通常需要针对每个特定工作负载进行微调。

为 VDA 选择哪种 AWS EC2 实例类型在很大程度上取决于特定的工作负载和交付类型。但是,作为一般准则,“M”系列实例通常最适合托管共享,而“T”系列实例则适用于 VDI。“M”系列平衡了 CPU 和 RAM,专为在主机上的多个会话中大部分可预测的资源消耗而设计。“T”系列本质上是“可突发的”,专为 VDI 的大多数不可预测的特征而设计(例如,用户空闲一分钟,下一分钟他们正在运行宏计算)。有关实例类型选择和定价的更多详细信息,读者可以参阅 Citrix on AWS 成本估算演示文稿 (位于“来源”部分)。

有关实例选择的更多信息(尤其是当它适用于托管共享交付模型时),请参阅 Citrix Scalability in a Cloud World –2018 Edition。 本文虽然稍微过时,但讨论了有关基于性能、可管理性、成本、预留与按需定价模型以及 LoginVSI 可扩展性测试的实例选择的领先实践。 尽管自初次发布以来,实例选择和定价可能发生了变化,但这些概念和注意事项今天仍然有效。

*注意:默认情况下, 某些较新的 AWS 实例类型不会显示在 Studio 的计算机目录创建向导中(CVAD 或 DaaS)。 用户界面由驻留在 Delivery Controller (CVAD) 或 Cloud Connector (DaaS) 上的静态 XML 文件中的实例类型填充。可以修改此 XML 以包括较新的实例类型,但在升级期间(Citrix 启动的 Cloud Connector 更新或客户启动的 Delivery Controller 升级)期间,此文件将被默认值覆盖。有关如何更新可用 AWS 实例类型列表的更多详细信息,请参阅 CTX139707 。* 在本轮测试(时间点参考)中,M5.2Xlarge 实例类型(8vCPU,32 GB RAM)在每用户/小时(使用行业标准样本工作负载)方面成为赢家。鉴于您的特定工作负载特征和可用的 AWS 定价,您的数字可能会有所不同,但是流程和工具可用于更准确地估算每月 IaaS 成本。无论您如何确定开始使用的实例类型,都必须监视一段时间内的使用情况,并根据需要进行调整,以保持资源可用性、消耗和成本之间的平衡。客户应考虑使用诸如 Citrix Analytics for Performance 之类的服务,此类服务提供的信息在保持性能提升和降低成本方面可以发挥关键作用。

应用设计

额外的考虑包括应用程序设计。当客户计划将工作负载迁移到 AWS 之类的云平台时,他们必须确保应用程序性能不受影响。应用 20 多年的经验法则是,数据应尽可能接近工作负载。这意味着更复杂的应用程序架构应该遵守这一规则。 这方面的一个示例包括具有前端和后端(数据库)的应用程序。 为避免增加会影响应用程序性能的延迟,需要迁移前端和后端。另一种选择是混合方法,混合使用内部部署(对于复杂应用程序)和云托管工作负载(对于简单应用程序)。务必始终咨询应用程序供应商以了解兼容性。链接的 Tech Zone 决策矩阵比较 了不同的托管共享交付方法,其中包括托管共享应用程序(单用途和多用途)和托管共享桌面。这些文章概述的工作负载细分决策过程可用作工作负载设计过程的指南。

关于应用程序设计的最后一句话,Enterprise Layer Manager 设备目前不在 AWS 上运行,目前不支持将分层映像导出为可立即使用的磁盘格式以便在 AWS 上使用。如果 AWS 上的App Layering 支持对于您的迁移或部署至关重要,请发送电子邮件至 aws@citrix.com,告知您的项目相关信息。您将被添加到列表中,以成为未来版本的早期采用者候选人,并且您的声音将被听到。有关 Citrix App Layering 的更多信息,请参阅 产品文档App Layering 参考体系结构

控制层注意事项

在 Citrix 体系结构设计框架中,控制层定义了控制 Citrix 解决方案的组件。这包括 Active Directory(森林/域、OU 和用户组结构、组策略等)、Microsoft SQL 数据库使用情况、Citrix 许可、会话代理和管理、负载管理和 VDA 预配/映像管理等组件。与本文档的前几节一样,我们在此侧重于 AWS 上的 Citrix 虚拟化系统最重要的注意事项,并提供指向有关其他人的现有文档/指南的链接。

您对控制层组件做出的最有影响力的决策之一是会话代理和管理选择。此决策至关重要,对成本、复杂性、可用性和持续维护工作具有重大影响。我们首先回顾本文档前面介绍的部署模型,然后深入了解 AWS 的具体注意事项。

控制层:Greenfield /仅云部署

绿色领域或仅云部署模型全面使用云服务。n)。AWS 对 Citrix 虚拟化系统设计的具体影响很小,但无论如何,我们都会引导您完成这些影响。由于 Citrix Cloud 将大多数基础架构和管理组件作为服务提供,因此您不必担心 SQL 数据库、Citrix 许可证服务器、Citrix Director 服务器等问题。

控制层:混合部署

请记住,使用混合部署模型,您将构建/管理一些 Citrix 虚拟化系统组件,否则根据定义,这是一个绿色领域或仅限云部署。 这里有趣的是,在控制层的上下文中,它们几乎完全相同。

控制层:直接迁移部署

使用传统的直接迁移部署模型,您将在 AWS 上部署所有关键控制层组件(包括 Active Directory 和所有 Citrix 会话代理/管理组件)。如果您必须沿着“直接迁移”的道路走,那既是祝福又是诅咒。这是一件幸福,因为大多数这些考虑因素已经在已发布的各种已出版的著作中得到了充分的记录。这是一个诅咒,因为在构建、管理、保护和维护这些组件方面,无论是预先还是随着时间的推移,您都需要做更多的工作。

如果您是“直接迁移”者,则希望在继续之前查看并参考以下内容:总体来说,这些决策涵盖了使用直接迁移部署模型成功部署 Citrix on AWS 所必须考虑的大多数设计决策:

Active Directory 的考虑

AWS 上 Citrix 虚拟化系统的所有部署模型都需要 Microsoft Active Directory。为获得引人注目的用户体验,必须在部署 VDA 的每个 AWS 区域提供功能性 Active Directory 服务。必须仔细考虑 Active Directory 实施的结构和复杂性,但幸运的是,Citrix 虚拟化可以灵活地与各种不同的 AD 设计和服务模型集成。

在 AWS 上部署 Active Directory 时,客户可以使用 Windows Server 实例构建/维护自己的 Active Directory 域控制器、使用 适用于Microsoft Active Directory 的 AWS 目录服务或两者的组合。Active Directory 信任也可用于连接两个或多个 AD 森林/域,具体取决于客户的需求。

对于希望最大限度地减少构建和维护有效的 Active Directory 服务所需的管理开销的客户来说,面向 Microsoft Active Directory 的 AWS 目录服务 (也称为 AWS 托管Microsoft AD)是一个值得考虑的选择。此服务为您提供功能齐全的 Active Directory 森林/域,无需构建和维护 Windows Server 虚拟机实例的开销。AWS 托管的 Microsoft AD 建立在高度可用、AWS 托管的基础设施之上。每个目录都部署在多个可用区域中,监视会自动检测并替换失败的域控制器。此外,还为您配置了数据复制和自动每日快照。您不必安装软件,AWS 会处理所有修补程序和软件更新。 借助 AWS 托管 Microsoft AD,您可以使用本机 Microsoft 管理工具、使用 Microsoft 组策略管理 Windows 计算机和用户、将 EC2 实例和 AWS RDS for SQL Server 实例加入到其中,甚至可以使用现有 AD 实例设置 Active Directory 信任以支持各种复杂的企业场景。

选择将 AWS 托管 Microsoft AD 服务与 Citrix 虚拟化技术结合使用的客户可以期待这些技术与此 AWS 服务配合使用,但在此之前需要考虑一些重要注意事项。对于初学者来说-您将没有域管理员、企业管理员或其他“超级用户”类型访问 AD 实例的访问权限。但是,您确实可以在目录的根目录中完全控制自己的容器,从中创建用户、计算机、组、OU 和组策略。

您不能做的其他一些事情:

  • 在任何默认容器(例如 /Computers)中创建 AD 对象:它们是只读的。这就引发了一些客户在使用 Citrix 的 MCS 配置技术时犯的一个常见错误:您必须选择在可写容器 /OU 中为 MCS 托管 VDA 创建计算机帐户-如果不选择此位置,MCS 将无法创建计算机帐户。
  • 安装和配置某些 AD 集成功能,例如证书服务。因此,这会影响将使用 Citrix 的联合身份验证服务 (“FAS”) 技术(需要 AD 集成证书服务)的客户:这些客户必须使用 EC2 Windows Server 实例在 AWS 上构建和管理自己的 Active Directory。
  • 默认情况下具有本地服务器管理员等效。默认情况下,在“开箱即用”的 Active Directory 安装中,域管理员组会添加到本地服务器管理员组。如果您使用的是 AWS 托管 Microsoft AD 服务,则必须创建自己的服务器管理员组,向该组添加自己的用户,创建并应用组策略以将组添加到成员服务器/工作站上的内置服务器管理员组中。

虽然本白皮书不涉及信任关系、站点/服务配置、复制和其他与 AD 相关的主题,但 Citrix 提供了有关这些适用于所有三种部署模型的主题的大量文档。

*注意: 适用于Microsoft Active Directory 的 AWS 目录服务 是一项“Citrix Ready 验证”产品。尽管 Citrix 没有正式支持,但该服务基本上是 Microsoft Active Directory 的原生服务-它只是由 AWS 而不是客户管理。此 AWS 服务确实有一些限制,无法将其大规模交付为服务,此处列出了当前已知/最具影响力的 Citrix 环境限制。* 有关绿地和混合部署(使用 Citrix Cloud 和 CVAD 服务进行会话代理和管理的环境)的 Active Directory 要求的更多信息,请参阅 Citrix Cloud Connector 技术详细信息。 除了涵盖 支持的 Active Directory 功能级别外,本文还介绍了 Active Directory 中 Cloud Connector 的部署场景

有关 Active Directory 升降部署(使用 Citrix Virtual Apps and Desktops LTSR 或 CR 版本使用客户托管会话代理和管理的环境)的更多信息,请参阅 CVAD 系统要求,Active Directory 功能级别

会话代理和管理注意事项

正如您现在可能已经收集到的那样,选择如何提供会话代理和管理服务至关重要,并且对 Citrix 虚拟化系统的总体成本、可管理性、维护和可用功能产生广泛影响。正如我们已经讨论过的那样,Citrix 建议将 Citrix Cloud 服务 (DaaS) 用于此关键组件,但对于某些要求和场景,部署客户托管的会话代理和管理子系统(通过 CVAD LTSR 或 CR 版本)可能是必要的,也可能是推荐的。下表重点介绍了其中一些要求和场景,供您考虑:

属性/能力 客户管理的 CVAD(Citrix Virtual Apps and Desktops、LTSR 或 CR 版本) 云服务 DaaS(Citrix Cloud 提供的 Citrix DaaS)
需要到 Citrix Cloud 的出站 Internet 连接。 - Delivery Controller 不需要出站 Internet 连接,尽管他们必须能够与 AWS 基础设施进行通信才能使 MCS 配置正常运行。 - Cloud Connector 通过 Internet 与 Citrix Cloud 进行通信,但这些连接可以代理。有关更多详细信息,请参阅 如何为 Citrix Cloud Connector 设置代理服务器 。对于严格空缺的部署来说,这通常是一个节目阻塞器。
要求客户提供高可用性的 Microsoft SQL 数据库服务。 -CVAD(LTSR 和 CR 版本类型)要求客户提供高可用性的 Microsoft SQL 数据库服务。可以通过在 EC2 实例上构建 SQL Server 或使用 AWS RDS for SQL Server 服务来实现这些功能。 -DaaS 不要求客户接触 SQL 服务器:高度可用的数据库服务由 Citrix Cloud 交付平台提供,对客户是透明的。
要求客户随着时间的推移对 Citrix 软件应用修补程序和升级,以维护安全性和可支持性,并获得新的功能和功能。 -客户负责安装、配置、修补、保护和升级基于 CVAD 的会话代理和管理系统中所有组件的 Citrix 软件和底层操作系统。他们还负责维护每个组件的高可用性,包括 Citrix Delivery Controller、Studio 安装、Director 和 Citrix Licensing。 -Cloud Connector(驻留在客户 VPC 中的唯一会话代理和管理组件)将由 Citrix 自动更新和维护。客户负责在 EC2 Cloud Connector 实例上修补和维护 Windows Server 操作系统 ,新的特性和功能可立即使用,而无需客户手动更新Cloud Connector。
能够使用 Citrix Cloud 提供的高级服务,包括 Citrix AutoScale 功能 有时 -并非所有高级服务都可供客户管理的 CVAD 部署使用,如果是这样,可能需要安装和配置额外的组件。自动缩放功能不适用于 CVAD 环境。 -DaaS 旨在与其他 Citrix Cloud 服务“开箱即用”工作,这些服务通常是预先配置的,因此客户只需将其开启即可。 AutoScale 功能提供了精细控制 VDA 数量和电源状态的功能,它对公有云上的 VDA 部署具有影响力。在您只为所需容量付费的情况下,它可以大幅节省基础设施成本。
能够完全控制所有子系统组件,包括升级和维护活动的时间。 -由于每个组件都由客户安装、配置和维护,因此客户可以完全控制每个组件的版本控制、配置和可用性(尽管基础架构、复杂性和管理开销的成本大大增加)。 不能 -使用 DaaS,客户放弃了某种程度的控制,但获得了简便性,降低了基础架构成本,并大大减少了管理开销。
能够根据并发用户与指定用户进行许可。 的-CVAD 可以由 CCU 授权。 的-CCU 许可可可用。有关详细信息,请参阅 此博客

Cloud Connector、Delivery Controller 和资源位置

由于绿地和混合模型都使用云服务 (DaaS) 进行会话代理和管理,因此您可以部署 Cloud Connector 以在计划托管 VDA 的每个区域中创建 资源位置 。在区域中创建资源位置时,您可以通过部署 n+1 个 Cloud Connector 实例并将Cloud Connector分布到该区域的可用区来构建高度可用的配置。Cloud Connector通常放置在与 VDA 不同的私有子网中,以简化安全策略应用程序,而 Cloud Connector 实例必须具有出站 Internet 访问权限才能方便连接到 Citrix Cloud。将它们放在与 VDA 不同的子网中允许管理员对两种不同的资源类型应用不同的路由策略。

图 13:Citrix DaaS 资源位置设计模式为 VDA 和使用单独 Cloud Connector 的子网 图 13:Citrix DaaS 资源位置设计模式,VDA 和 Cloud Connector 具有单独的子网。

当我们谈论 Delivery Controller (CVAD) 时,同样的一般概念也适用,尽管我们在客户管理的 Broker 子系统中使用术语区域与资源位置。另请注意,EC2 上的 Cloud Connector 实例是预留定价的理想选择,因为它们在系统需要启动的时候运行。有关调整Cloud Connector 实例大小的更多信息,请参阅 本文

Citrix DaaS 站点设计注意事项

资源位置和区域

使用 Citrix 区域 (不要与可用区混淆)可以帮助远程区域的用户连接到资源,而不必强制他们的连接遍历广域网的大片段。在 Citrix DaaS 环境中,每个资源位置都被视为一个区域。创建资源位置并安装 Cloud Connector 时,将自动为您创建一个区域。每个区域可以包含不同的资源组,具体取决于您的独特需求和环境。有关区域的更多信息,请参阅以下 链接

计算机目录、交付组和资源位置

Citrix 管理员应确保 VDA 也分布在可用区 (AZ) 之间。AWS 可用区 (AZ) 是一个或多个具有冗余电源、联网和连接功能的独立数据中心,在 AWS 区域是 AWS 群集数据中心的全球物理位置。虚拟私有云 (VPC) 是跨越区域可用区的虚拟网络。子网是 VPC 的必需子组件,虚拟网络接口每个都附加到单个子网。每个子网必须完全位于一个可用区内,且不能跨区域。通过在不同的可用区中启动 VDA,您可以保护应用程序免受单个位置故障的影响。 请参阅 什么是Amazon VPC? 了解更多信息。为确保 VDA 在可用区之间分布,您可以为每个可用区创建一个计算机目录(每个可用区使用一个主机连接),然后该目录可以映射到单个交付组。

AWS 中的配置:Machine Creation Services

从 CVAD 1811 版本开始,在 AWS 中为 MCS 配置创建主机连接时,可以使用基于角色的身份验证。 与 EC2 实例上的 Delivery Controller 或 Cloud Connector 关联的 IAM 角色或 IAM 用户帐户可用于取代用户的私有密钥和 API 密钥,从而提高安全性、委派管理权限以及具有临时凭据和会话令牌的基于 PKI 的环境。要使用基于角色的身份验证配置主机连接,请先创建具有 CTX140429中所述权限的 IAM 角色。 将此角色与具有 CVAD 1811+ Delivery Controller 或Cloud Connector 器的 EC2 实例 关联。 在 1811 之前的 CVAD 版本上,管理员必须提供 IAM 用户的 API 密钥(访问密钥)和私有密钥才能创建主机连接。

创建主机连接后,使用从 AWS 中的主 VDA 映像创建 AMI 创建计算机目录,如下所述。有关 AWS 中 MCS 的更多详细信息,请参阅以下文章: AWS 上的 Citrix MCS 深入探讨 1在 AWS 中创建池 VM 后 MCS 的工作原理

使用 MCS 在 AWS 中部署 VDA 时应考虑的另一个事项是 EBS 卷初始化 (也称为预热或补水)。对于从快照还原的卷,必须先从 Amazon S3 中提取存储块并写入卷,然后才能访问它们。此初步操作需要时间,可能会导致首次访问每个数据块时 I/O 操作的延迟显著增加。在将所有数据块下载并写入卷之后,就可以实现卷性能。请参阅在 Windows for AWS 上初始化 Amazon EBS 卷在 Windows 实例上初始化 Amazon EBS 卷的推荐步骤,以及请参阅在 Linux for Linux 实例上初始化 Amazon EBS 卷

有关与 MCS 相关的 VPC 设计的详细信息,请参阅 基础架构(或平台)层注意事项

Machine Creation Services 故障排除

本节列出了一些常见问题和相关的建议/解决方案链接。

基础架构(或平台)层注意事项

在 Citrix 体系结构设计框架中,基础架构(或平台)层定义了 Citrix 工作负载运行的物理元素。在本文档中,这当然是指 AWS。AWS 提供了许多云服务 (165 多个),是当今存在的最古老和最大的超大规模云提供商。它也是 Citrix 虚拟化技术支持的第一个公有云,对于希望在“云”中移动现有或运行新的 Citrix 虚拟化工作负载的新客户或现有客户来说,它是一个极具吸引力的选择。

基础设施即代码和 AWS 对象模型

要了解 Citrix 虚拟化技术如何与 AWS 集成并在 AWS 上运行,最好从基本了解其一些关键/相关服务背后的对象模型开始。这也使我们能够用大多数 IT 专业人员熟悉的术语来描述 AWS 平台。为便于理解,我们参考下图表示 AWS 上 DaaS 资源位置的设计模式:

图 14:为 Citrix DaaS 和 AWS 部署的“资源位置”架构/设计模式 图 14:在 AWS 上为 Citrix DaaS 部署的“资源位置”架构/设计模式。

这种设计模式是 AWS 上大多数 Citrix 虚拟化系统架构的基础。它不仅仅是一种庞大的模式,它建立在 AWS 上企业 IT 的各种不同、维护良好且有文档记录的设计模式之上。这些模式是使用 AWS CloudFormation 模板来表示、记录和复制的。AWS 提供了一个 快速入门模板库,这些模板 可以按原样运行,与其他模板分层(“嵌套”),甚至可以根据自己的特定需求进行复制和自定义。这突出了公共云基础设施的其他几个主要优势: 基础设施即代码,以及许多云服务的“按需付费”性质。我们不久将更深入地研究 Citrix 虚拟化世界中的基础架构作为代码,但我们强调了快速接触点,这可能会引起本文的预期读者共鸣:对于许多企业 IT 架构师来说,可以访问如此庞大的服务库、设计模式和触手可及的技术工具非常棒。再加上在消耗资源时支付资源费用并在完成后简单地将其删除的能力相结合?这是了解或评估新东西的强大方法,它使大规模投资的投资回报率更容易理解和沟通。

稍微回到 AWS 对象模型:图 14 中的顶级对象是 AWS 区域。 您可以将 AWS 区域视为由连接良好但战略上分离的数据中心组成的群集,称为 可用区。 每个区域通常包括 2 个或多个可用区,其中包括一个或多个具有冗余电源、网络和连接的物理建筑物。截至撰写本文时,AWS 在全球拥有 23 个区域,其中包括 69 个可用区,但需要注意的是,它们不断投资于新的区域和可用区。这些数字虽然令我们大多数人感到惊讶,但在您阅读本文时可能已经过时了。这突出了迁移到 AWS 上的公有云基础设施的其他好处之一:随着时间的推移,您将继续受益于他们正在进行的投资(规模远远超出了大多数 IT 组织甚至政府的能力)。这种持续的演变/改进虽然对于厌恶变革的 IT 组织和业务文化来说是令人望而生畏的,但在企业 IT 适应这种“新”模式的过程中为企业 IT 带来了广泛的赋权益处。

AWS 区域采用选择通常取决于邻近程度、可用服务、成本、合规性或 SLA。尽管为 Citrix 虚拟化系统选择一个或多个正确的区域不在本文档的讨论范围之内,但在做出选择时至少考虑以下事项:

  • 如果您有一个或多个现有的、由客户管理的数据中心 连接到 AWS,请考虑一个或多个区域,它们为您的数据中心和主要办公室提供最低延迟的网络连接。
  • 所有区域都不能拥有您要 查找的 AWS 服务或实例类型。AWS 最初将新的服务或实例类型部署到几个主要区域,然后随着时间的推移扩展到其余区域。 此外,较新的区域不能有较旧的实例类型-尽可能在构建之前进行研究。
  • CVAD 站点和 DaaS 资源位置绑定到 特定区域。通过将资源放置在给定区域的多个可用区来实现站点/资源位置的各个组件(例如Cloud Connector、StoreFront 服务器和 ADC/Gateway VPX 实例)的高可用性。
  • 不要过度扩展基础设施跨区域: 虽然在 AWS 上很容易实现,但在扩展任何系统之前,请考虑成本和复杂性与您预期的收益相关的成本和复杂性。您最终有时也会为网络流量和存储流量付费。当流量在某个区域本地时,流量的成本可能微不足道,但是当流量穿越区域或 Internet 时,成本会增加。

现在,我们来看看此设计模式中的一些网络结构。AWS 上的主要网络构造是 VPC 或“虚拟私有云”。VPC 是一个区域结构(跨越可用区)-在部署 Citrix 虚拟化技术的每个区域中,您至少有一个 VPC。VPC 定义了 CIDR IP 地址块,如果您的网络设计在多个 VPC 之间路由流量,则必须是唯一的。VPC 进一步细分为子网,子网将绑定到可用区域(也就是说,它们不跨越区域中的可用区)。

子网还具有不同的属性和对象,包括路由策略和安全策略。这就是为什么本文档(以及其他 Citrix 文档)中突出显示的设计模式建议将 VDA 放在与 Cloud Connector 不同的子网中的原因,以便您可以为 VDA 和Cloud Connector分配不同的路由和安全策略。

VPC(区域结构)中任何子网的出站 Internet 访问可以通过多种不同的方式进行处理,但一种常见的方法是使用 NAT 网关 为私有子网提供 Internet 连接。公有子网通常由 Internet 网关提供服务,这有助于将入站连接路由到您可以从 Internet 访问的服务。

子网通常也被标记为“公共”和“私有”。公有子网是指分配 Internet 可路由 IP 地址的子网(除私有 IP 地址外),并与路由表相关联,该路由表具有通往 Internet 网关 (IGW) 的路由,用于入站和出站 Internet 流量。私有子网是一个只分配了私有 IP 地址的子网,它与路由表相关联,该路由表具有通过 NAT 网关或位于公有子网中的 NAT 实例进行出站 Internet 访问的路由。在 Citrix 虚拟化系统中,网关虚拟服务器 (VIP) 通常位于公有子网中,因为它通过 Internet 接受来自客户端设备的入站连接,并用于将 Citrix 虚拟化流量安全地代理到 VPC 中的私有子网。

在 AWS 上构建网络的方法有很多,其他地方无法获得的许多创新功能和技术。我们不打算在这里向您介绍所有这些,但值得研究的两个工具/技术是 VPC 对等传输网关。这两种结构可帮助您简单地在 VPC 之间路由流量(VPC对等),或者在更适合企业的混合云友好模式(中转网关)中路由流量。

我们可以在这里深入了解更多内容,对于好奇和积极性,您的指尖有大量公共领域知识可供您了解更多信息。现在,让我们把它带回到您在本文中看到的所有图下的设计模式。

AWS 平台的一个引人注目的特征是它是基于公开消费的 API 构建的。为什么这令人信服?首先,这意味着您可以在 AWS 上运行的任何类型的基础设施组件都可以通过代码重复构建。与强大而全面的部署服务(如 AWS CloudFormation)结合使用时,客户将拥有一个强大的框架来学习、自定义、部署和管理 IT 系统。“基础设施即代码”的概念对于许多传统的以企业为 中心的技术人员来说可能是新的或令人困惑的,但一旦被采纳和实践,它可能会带来变革。

正如我们前面提到的,AWS 提供了一个基于 CloudFormation 的 快速入门模板 库,这些模板可以按原样运行,与其他模板分层(“嵌套”),甚至可以根据自己的特定需求进行复制和自定义。此模板库由 AWS 与 Citrix 等技术合作伙伴合作管理和维护,这些模板通常是开源的(这意味着可以根据需要复制和修改模板)。截至撰写本文时,以下快速入门模板可用于 AWS 上的 Citrix 技术:

  • 适用于 Web 应用程序的 Citrix ADC - 在 AWS 上部署高可用性的 Citrix ADC VPX 实例。虽然用例重点略有不同,但这种设计模式是实用的,也适用于使用 CVAD/DaaS 的 Citrix Gateway 部署。

摘要-了解 AWS 上 Citrix 的设计模式

还困惑了吗?如果是这样,请不要感到震惊:这很可能是 Citrix on AWS 公有云之旅的开始,而我们只是在这里浏览了许多深度话题的表面。但是,希望我们成功地说明了以下要点:

  • 基础设施即代码是一个强大的概念,可以彻底改变整套系统的设计、构建和维护方式。
  • 在 AWS 的公有云上部署系统时,任何给定解决方案的不同组件都可以通过代码表示,也可以使用 AWS CloudFormation 和其他技术按需构建。
  • 使用 AWS CloudFormation 时,这些组件由堆栈模板表示,并且可以根据需要复制和修改模板以达到所需的结果。
  • 模板可以嵌套,根据单独的设计模式(模板)构建完整的系统(例如 AWS 上功能齐全的 DaaS 资源位置)。
  • AWS 上的 Citrix DaaS 快速入门模板建立在三个 AWS 托管/维护的基础模板之上,这些模板有据可查。从以下链接开始,了解有关每个链接的更多信息:
  • 通过使用模板和执行试用版本,企业技术专家可以了解、评估和设计满足其组织或客户特定需求的系统。

AWS 基础设施层 — 额外的资源

以下资源可用于帮助更多有关 AWS 上的 Citrix 虚拟化要求和领先实践的信息:

操作层注意事项

本节定义了管理员定期执行的操作活动。其中许多不是 AWS 特定的,在现有已发布的文档中有详细说明。在下表中,我们总结了一些更重要的或 AWS 特定的任务。读者可以参阅 Citrix 产品文档中的监视器主题以了解更多信息。

按需任务

下表概述了根据应用程序要求和故障排除工作预计按需执行的任务。

组件 任务 说明
通用 更新知识库 Citrix 团队对与环境相关的问题进行故障排除时,他们将确定问题的解决方案。应为每个问题创建 KBA,以帮助支持未来的故障排除活动。
Citrix DaaS 修改图像 图片将根据需要进行更新以支持请求。更新可能每月进行,但可能需要更频繁的更新才能进行测试。
Citrix DaaS 发布图片 修改图像时,会对其进行测试和发布。
AWS 验证实例启动 当通过 MCS 启动新实例时,请验证实例是否已在 AWS 控制台中创建,以及给定 VPC 的池中是否有可用的 IP。如果 VPC 池中没有可用的 IP,则不会创建 MCS 置备的计算机。
AWS 验证本地图像的功效 从任何本地映像创建的实例在用于更新生产实例之前,应对其可启动性和可行性进行测试。
AWS 修改IAM 用户/组权限 根据需要,应审查 IAM 用户和组权限,以减少具有管理访问权限的用户数量,并实施“最低权限”方法。
AWS 修改安全组 根据需要,将对安全组进行审查,以授予或删除对来自不同 IP 或 IP 范围的不同流量协议的访问权限。将修改入口和出口规则以实施网络流量封锁。
AWS 和 Citrix DaaS 更新计算机目录中的计算机 根据需要,更新计算机映像以包含任何必要的修改。必须为修改后的映像创建新 AMI,并用于更新计算机目录。有关详细信息,请参阅本文档的更新和升级过程部分。
AWS 和 Citrix DaaS 将更新回滚到计算机目录 根据需要,如果必须回滚计算机映像,则可以使用具有最后一个已知工作配置的先前 AMI 来更新计算机目录中的计算机。

每日定期任务

下表概述了应该每天执行的任务。

组件 任务 说明
通用 查看 Citrix Director、Windows 性能监视器、事件日志和其他监视软件警报 检查 Citrix Director、事件日志或其他监视软件中的警告或警报。调查警示的根本原因(如果有)。注意: 可以将计算机和显示器设置为显示 Citrix Director 控制板,以便为 Citrix 部门创建平视显示屏,以便清楚地显示环境状态。Citrix Virtual Apps and Desktops 的监视建议包含在 Virtual Apps and Desktops 最佳实践指南的“监视”部分中。
通用 验证备份已成功完成 验证所有计划的备份是否已成功完成。这可以包括但不限于用户数据(用户配置文件/主文件夹)、应用程序数据、Citrix 数据库、Citrix StoreFront 配置、Citrix 许可证文件。
通用 测试环境访问 在大多数用户登录当天之前,模拟内部和外部连接,以验证桌面和应用程序资源是否可用。这种连接将全天进行测试,甚至可以自动化。
Citrix Virtual Apps and Desktops 虚拟机电源检查 验证是否已打开适当数量的空闲桌面和应用程序服务器并向 Delivery Controller 注册,以确认用户工作负载的可用性。
AWS 执行例如运行状况检查 检查 AWS 控制台以验证实例和底层硬件的状态。打开电源后,所有实例都应通过两项运行状况检查。
Citrix Virtual Apps and Desktops 执行 Citrix 相关数据库的增量备份 对以下 Citrix 数据库执行增量数据备份:站点数据库、配置日志记录数据库、监视数据库

每周定期任务

下表概述了每周要执行的任务。

组件 任务 说明
通用 查看最新的修补程序和补丁程序 查看、测试和部署最新的 Citrix 修补程序,并确定 Delivery Controller 和基于服务器的操作系统/基于桌面的操作系统虚拟机是否需要这些修补程序。对于通过 SCCM 或 WSUS 部署到 AWS 中计算机的 Microsoft 更新,所有计算机在打开电源时都会收到这些更新。如果使用 Citrix Power Management,则计算机目录中可能有未定期打开的计算机。执行映像更新时,最好使用在所有更新周期内打开的动态主实例。然后可以从此实例创建 AMI 并包含所有必要的修补程序。注意: 在生产环境中实施之前,任何必需的修补程序都必须使用推荐的测试流程进行测试。
通用 创建 Citrix 环境状态报告 创建有关整体环境性能(服务器运行状况、资源使用情况、用户体验)和 Citrix 问题数量(关闭率、未解决问题等)的报告。
通用 查看状态报告 查看 Citrix 状态报告以确定任何趋势或常见问题。
通用 维护内部支持知识库 创建 KBA 和问题解决脚本以解决 1 级和 2 级支持请求。查看 KBA 并发出解决脚本,了解准确性、合规性和可行性。
Citrix Virtual Apps and Desktops 检查 配置记录报告 确认上周实施的 Citrix 站点范围内的更改已通过更改控制获得批准。
Citrix Virtual Apps and Desktops 执行 Citrix 相关数据库的完整备份 对以下 Citrix 数据库执行完整数据备份:站点数据库、配置日志记录数据库、监视数据库
AWS 执行所有 EBS 卷的快照 所有弹性块存储卷都将定期拍摄快照。快照可以在 AWS EC2 控制台中进行管理和整理。

每月定期任务

下表概述了每月要执行的任务。

组件 任务 说明
通用 执行容量评估 对 Citrix 环境进行环境性能和容量评估,以确定环境利用率和任何可扩展性要求。查看监视工具的月度报告,以评估环境性能和容量,包括但不限于:虚拟服务器计算(CPU 和 RAM)分配、许可、网络带宽。根据需要购买软件和/或许可证并构建额外的服务器。注意: 执行容量评估的建议包含在“设计决策:单服务器可扩展性”中
通用 查看提升的权限访问 查看哪些用户和组对环境具有提升的权限,并评估是否需要持续提升的访问权限。删除任何不再需要这些管理权限的帐户。主要仅限用于分配提升权限的 IAM 用户和角色,并严格限制对个人用户、本地或根帐户的访问权限。

每年定期任务

下表概述了每年要执行的任务。

组件 任务 说明
通用 执行 Citrix 策略评估 查看 Citrix 策略并确定是否需要新策略以及是否必须更新现有策略。
通用 查看软件升级 查看并评估新 Citrix 软件版本的要求。
通用 执行业务连续性计划 (BCP)/灾难恢复 (DR) 测试 执行功能性 BCP/DR 测试,以确认 DR 已准备就绪。此计划包括年度还原测试,以验证备份数据的实际还原过程是否正常运行。
通用 执行应用程序评估 查看 Citrix 环境外部和内部应用程序的使用情况。评估向 Citrix 站点添加更多应用程序、删除不再需要的应用程序或将应用程序升级到最新版本的有效性。
AWS 评估网络安全组访问 在 Citrix 基础架构服务器或应用程序服务器中添加或删除功能或应用程序时,还将评估和修改与这些实例关联的网络安全组(如有必要),以添加或删除任何端口或协议。

来源

此参考体系结构的目标是帮助您规划自己的实施。为了简化这项工作,我们想为您提供源图,您可以在自己的详细设计和实施指南中进行调整: 源图

参考架构:Citrix DaaS-AWS