AWS 上 Citrix Virtual Apps and Desktops 的参考体系结构

受众和目标

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

概述和执行摘要

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

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

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

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

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

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

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

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

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

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

关键概念和部署场景

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

技术采用模型

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

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

客户托管

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

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

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

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

图 1:使用 AWS 作为 IaaS 的 100% 客户托管、提升/转移部署 图 1:使用 AWS 作为 IaaS 的 100% 客户托管、提升/转移部署。

云服务

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

今天,构成 Citrix 虚拟化系统的许多组件或层都可以 “作为服务” 使用。“ 与 “客户管理” 采用模式(客户将技术作为企业资产购买并自行构建/维护系统)相反,客户 “订阅” 各种服务,服务提供商承担提供和管理这些服务的责任。这些服务通常通过公共网络(即互联网)消费,导致一些人称之为 “云服务” 或 “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) 版本。如果您在环境中安装并配置交付控制器,则这就是您正在运行的。这也意味着你正在安装和管理自己的 Microsoft SQL Server 基础架构。客户托管 (CVAD) 部署中的管理功能包括 Citrix Director 和 Citrix Studio。您可以使用 LTSR/CR 二进制文件自行安装、配置和管理这些文件。Director 还需要微软 SQL Server 基础架构。Citrix 许可也是此子系统的一部分,客户可以安装/配置/管理 Citrix 许可证服务器和许可证文件。 CVADS-Citrix Virtual Apps and Desktops 服务,通过 Citrix Cloud 提供。如果您要登录 Citrix Cloud 并在环境中安装和注册云连接器,则表示您正在使用此 Citrix Cloud 服务。您可以在管理的 Windows 实例上安装和注册云连接器,然后 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 管理/经纪环境( CVADS) 的应用程序和桌面。 Citrix Workspace (服务,而不是 Citrix Workspace 应用程序)。通过 Citrix Cloud 作为云服务提供,并包括许多仅在此服务中可用的下一代功能。可以聚合和展示来自客户管理/代理环境 (CVAD) 和 Citrix Cloud 管理/经纪环境( CVADS) 的应用程序和桌面。
身份验证 -在这种情况下,我们指的是用户在访问 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、谷歌云 ID 或其他 SAML/openID/RADIUS 提供商。某些情况需要客户管理的 Citrix ADC/Gateways 和 Citrix 联合身份验证服务 (FAS) 才能获得最佳的用户体验。
HDX 会话代理 -能够安全、无缝地将私有企业网络外的用户/设备连接到 CVAD/CVADS 在内部交付的应用程序和桌面。 Citrix ADC/Gateway 设备-这些设备(或实例)通常为 Citrix 虚拟化系统提供大量额外功能。但是,他们的核心任务是在客户端处于公共网络上时,将 HDX 会话安全地代理到 VDA。需要安装、配置、SSL 证书等。兼容 StoreFront(客户托管的 UI 服务)和 Workspace 云服务。还兼容 Citrix 托管和客户管理的会话代理选项。 Citrix Gateway 服务 -由 Citrix Cloud 提供,该服务将 HDX 会话流量代理到您的 VDA,并使用 Citrix 托管基础设施完成工作。无需公共 IP 地址、SSL 证书或入口防火墙规则即可运行。与 Citrix Workspace 服务以及 Citrix Cloud 托管和客户管理的会话代理选项(CVAD 和 CVADS)兼容。

领先的实践和建议

无论您是自己管理 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/Gateways 进行 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 和 Virtual Apps and Desktops 服务的试用订阅或付费订阅。有了这两种资源,您可以使用 AWS 的 QuickStart CloudFormation 模板构建参考部署。Citrix 和 AWS 合作开发了 AWS 上的 Citrix Virtual Apps and Desktops 服务 快速入门模板,该模板可帮助您从头开始构建整个 Citrix 虚拟化系统,或者在具有现有 Active Directory 的现有 VPC 中创建 Citrix Cloud “资源位置”。从头开始部署整个 Citrix 虚拟化系统时,AWS 上生成的系统与以下参考架构图非常匹配:

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

图 4:Greenfield /仅云部署概念架构,可选 AWS 服务和 Citrix Cloud 服务 图 4:Greenfield/仅限云部署概念架构,可选 AWS 服务和 Citrix Cloud 服务。

值得注意的是,此部署模型(实际上,所有三种部署模型)都用 AWS 可用区 来提供高度可用的设计。有关详情,请参阅本文档后面的可用区部分。

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

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

Citrix 虚拟化系统组件 提供方:
会话经纪和管理 Citrix Virtual Apps and Desktops 服务(“CVADS”,通过 Citrix Cloud)
UI 服务 Citrix Workspace 服务(通过 Citrix Cloud)
身份验证 Citrix Workspace 服务(通过 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 和文件系统 面向微软 Active Directory 的 AWS 目录服务适用于 Windows 文件服务器的亚马逊 FSX (可选)

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

混合部署

使用混合部署模式,客户可以选择自己安装/配置/管理部分 Citrix 虚拟化系统组件,但不安装会话代理和管理子系统。在混合部署模式中,此子系统作为名为 “Citrix Virtual Apps and Desktops 服务” 的云服务提供(简称 CVADS),并以 Citrix Cloud 的订阅形式提供。

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

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

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

Citrix 虚拟化系统组件 提供方:
会话经纪和管理 Citrix Virtual Apps and Desktops 服务(“CVADS”,通过 Citrix Cloud)
UI 服务 Citrix Workspace 服务(通过 Citrix Cloud) Amazon EC2 上的 Citrix StoreFront(客户托管)
身份验证 Citrix Workspace 服务(通过 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 和文件系统 面向微软 Active Directory 的 AWS 目录服务适用于 Windows 文件服务器的亚马逊 FSX (可选)

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

图 5:概念架构、CVADS-AWS 上的混合部署模型 图 5:概念架构、CVADS-AWS 上的混合部署模型。

值得注意的是,此部署模型还用 AWS 可用区 来提供高度可用的设计。有关详情,请参阅本文档后面的可用区部分。

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

提升和转移

参照我们对的定义 Citrix 虚拟化系统组件,当我们谈论升降和换班部署方案时,关键组成部分是 会话代理和管理 子系统以及相关的基础架构。如果您使用的是 自我管理的代理基础架构 (您正在部署交付控制器而不是云连接器),那么为了本白皮书的目的, 您将提升和转移。

提升和转移-为什么

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

  • 系统隔离 -某些使用案例,例如没有互联网访问的空气间隙系统,通常会使升降和换班模式具有吸引力。由于云服务需要出站 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 实例; 面向微软 Active Directory 的 AWS 目录服务适用于 Windows 文件服务器的亚马逊 FSX (可选)

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

值得注意的是,此部署模型还用 AWS 可用区 来提供高度可用的设计。有关详情,请参阅本文档后面的可用区部分。

提升和移动部署模式通常与混合云基础设施模型相结合,使用 AWS Direct Connect、AWS VPN、Citrix SD-WAN 或类似的网络技术将客户托管的数据中心和资源连接到 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 的云服务进行会话代理和管理(仅部署云连接器,而不是部署交付控制器 + SQL 数据库 + Director 服务器 + Citrix 许可服务器)。以下是我们采取这一立场的一些主要原因(他们可能听起来很熟悉):

  • 简单性 - 虽然客户管理的会话代理服务 提供了最终的控制和配置灵活性,但它的代价是复杂性和持续维护需求。借助 Citrix Cloud 服务,简单性是基本的设计宗旨。当使用多个云服务时,它们会预先配置为协同工作,如果需要配置,工作流程和选项将大大简化。
  • 基础架构和许可成本节省 -客户管理的 Citrix 虚拟化服务通常需要额外的硬件和软件来支持它们,而且这些成本会产生与之相关 Microsoft SQL Server 就是一个很好的例子:客户管理的代理服务需要数据库,如果你要构建/管理自己的数据库,你必须提供它们。
  • 说到基础设施成本节省,这在两种会话中介选项 之间提供了一个关键的区别因素: AutoScaling。Citrix 的托管经纪服务 (CVADS) 包括 Citrix 自动缩放功能,它提供内置的 VDA 容量和成本管理功能。当客户只为使用的内容付费时,此功能可以为客户节省大量基础架构资金。在 AWS 上运行 Citrix 虚拟化工作负载时,这通常意味着为承诺使用折扣付费或随时支付虚拟机使用量之间的区别。对于许多使用案例而言,成本节约可能会显著,而 Citrix Autoscale 功能可帮助确保您只消耗所需的内容。重要说明: 此功能仅适用于 Citrix Cloud 服务(Citrix Virtual Apps and Desktops 服务)客户-客户托管的中介基础架构(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 架构设计框架中的其他层工作时应考虑的许多其他决策奠定了基础。因此,这是彻底理解和正确的关键层面。

幸运的是,这些注意事项已经有了充分的记录,在 AWS 上部署的系统和任何其他硬件/云平台上部署的系统之间没有很大差异。有关此层设计注意事项的全面入门手册,请参阅 适用于 XenApp 和 XenDesktop 的 Citrix VDI 手册和最佳实践 7.15 LTSR 文档,特别是 设计方法用户层 页面了解详细信息。

接入层注意事项

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

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

Citrix 虚拟化系统组件 提供方:
UI 服务 Citrix Workspace(由 Citrix Cloud 提供) Amazon EC2 上的 Citrix StoreFront(客户托管)
身份验证 Citrix Workspace 服务(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 Farm 展示和启动虚拟化应用程序和桌面。“ -旧版环境(XenApp 和 XenDesktop 6.5/7.x、Citrix Virtual Apps and Desktops CR/LTSR)和 Citrix Virtual Apps and Desktops 服务。 -旧版环境(XenApp 和 XenDesktop 6.5/7.x、Citrix Virtual Apps and Desktops CR/LTSR)和 Citrix Virtual Apps and Desktops 服务。有关详细信息,请参阅 本文
能够针对不同的用例(包括身份验证要求)创建多个具有不同设置的 “商店”。 -StoreFront 可以配置多个不同的应用商店,并且与 Citrix ADC/Gateway VPX 结合使用时,可以应用复杂的规则将某些设备或用户组定向到不同的应用商店。有关详细信息,请参阅SmartAccess 如何适用于 Citrix Virtual Apps and Desktops。需要两个 StoreFront Store 的一种常见情况是,用户需要从已发布的桌面内部发布的应用程序另一种常见情况是,要求为特定用例设置仅内部存储(无 Citrix Gateway 访问),并为内部和远程访问配置另一个应用商店。有关详细信息,请参阅配置和管理应用商店 -工作区服务基本上是单个商店,位于单个 URL 上。所有用户都使用相同的商店和工作区设置。身份验证要求只设置一次,并适用于 Workspace 租户的所有用户。
能够使用 Citrix Secure Workspace Access 服务枚举、启动和 SSO 到 SaaS 和 Web 应用程序中,利用 Web 筛选和增强的安全控制策略以及高级机器学习增强的分析。 -需要使用 Citrix Workspace。 -使用 Citrix Gateway 服务,只需在 Citrix Cloud 控制台中 “开启” 集成一样简单。SaaS 应用程序只需通过基于 Web 的向导进行定义,管理员可以使用大量预定义应用程序列表作为起点。
能够通过 Citrix Workspace 应用程序和 Web 浏览器 (HTML) 访问/索引/搜索 Citrix 文件(以前的 ShareFile)内容。 -StoreFront 无法将基于文件的内容集成到 Workspace 应用程序或 StoreFront HTML UI 中。 -默认情况下启用,具体取决于对 Citrix Cloud 的订阅。将来自各种来源(包括本地文件共享)的用户基于文件的内容引入 Workspace UI,包括 HTML 和 Workspace 应用程序。
能够使用 Citrix 远程 PC 访问 功能展示和启动与物理桌面的连接。 的-无论经纪活动是由 CVAD 还是 CVADS 处理。 的-无论经纪活动是由 CVAD 还是 CVADS 处理。
能够通过使用与各种不同 SaaS 和自定义应用程序集成的微应用来指导用户的工作并自动执行重复任务 -Citrix StoreFront 目前不可用微应用功能。 -在 Workspace UI 中向用户提供 “Feed”,该 Feed 可以智能地显示由机箱内和自定义微应用以及低代码微应用构建器控制台定义的通知、任务和工作流。有关更多信息,请参阅 Citrix Docs 上的 Workspace 智能功能 - 微应用微应用
对于多站点和灾难恢复用例,能够使用区域首选项和故障切换精确控制会话启动行为。 -使用 Citrix Zone 跨多个 AWS 区域和可用区进行部署是在停机情况下扩展东西部和限制受影响用户群的好方法,并允许区域首选项和无缝故障切换到主区域。请参阅 CVAD 区域文档 部分 -Workspace 服务不包括功能齐全的区域首选项和故障切换功能,但可以使用主区域为用户或应用程序实现类似的效果。有关详细信息,请参阅CVADS 区域文档
当资源位置/区域与 Citrix Cloud 之间的连接失败或 Citrix 交付控制器下的数据库不可用时,能够代理新的和现有的连接。 -使用云连接器和交付控制器上的本地主机缓存功能,为这两种潜在的故障情况提供弹性。对于具有广泛弹性要求的环境,Citrix 建议将 StoreFront 与本地主机缓存部署。有关详细信息,请参阅本地主机缓存 (CVAD) -在 Citrix Cloud 通信失败时,云连接器使用本地主机缓存功能来代理资源连接。这需要资源位置可访问的被动 StoreFront 服务器来处理故障转移方案。有关详细信息,请参阅本地主机缓存 (CVADS)
能够配置和利用自定义的 “虚荣 URL” 供最终用户使用。 -客户可以完全控制使用并向用户提供的 URL 和证书。通过公共网络进入是否需要 SSL 证书、DNS 别名创建/管理和 Citrix ADC/Gateway 实例。 部分 -所有工作区都从 cloud.com 域提供,但客户可以 配置自己的自定义前缀 (customername.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 Workspace 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 上的会话 -在使用联合身份提供商(如 SAML(安全断言标记语言)时,Citrix 联合身份验证服务 (FAS) 启用 SSO 到 VDA。 即将推出 -通过将 Citrix 联合身份验证服务 (FAS)与 Citrix Workspace 结合使用。截至撰写本文时,此功能处于预览中。有关详细信息,请参阅使用 Citrix FAS 为工作区启用 SSO

HDX 会话代理注意事项

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

属性/能力 客户托管(AWS 上的 Citrix ADC/Gateway VPX) 云服务(Citrix Gateway 服务 由 Citrix Cloud 提供)
简单的预配置服务,提供无管理开销的 HDX 代理 -作为客户管理的组件,这些设备需要许可、安装、配置和维护。 - Citrix Gateway 服务 是一个完整的 HDX 代理解决方案,由 Citrix 管理,作为云服务交付。
能够使用 Citrix HDX 的基于 EDT (UDP) 的传输协议。有关详细信息,请参阅自适应传输如何配置 HDX Enlightened Data Transport 协议 -此功能可优化来自高延迟站点的流量,可用于客户托管的 ADC/Gateway 实例。 尚未 -截至撰写本文时,此功能已处于预览中。网关服务目前仅支持基于 TCP 的 VDA 连接。
能够为客户托管的基础架构提供负载平衡、运行状况检查、SSL 卸载以及各种其他高级网络和应用程序交付服务。 -Citrix ADC/Gateway VPX 设备提供了复杂、业界领先的功能,其中许多功能只需将适当类型的许可证应用于设备即可启用。 -对于 Citrix CVAD 和 CVADS 中介环境,网关服务提供对在客户 AWS 或本地环境中运行的虚拟化应用程序的简单、安全的访问。
支持客户在数据中心、区域和区域之间可配置的全局服务器负载平衡 (GSLB)。 -可以为 GSLB 设置客户管理的 Citrix ADC/Gateway 实例,尽管客户负责设置和管理。 -… 但是没有真正的需要:Gateway Service 使用 全球 14 个或更多 POP 加上集成的 GSLB 来确保用户获得尽可能最佳的会话性能,无论他们身在世界何处。
需要使用 Citrix Workspace UI 进行 HDX 会话演示和启动。 -可以将客户托管的 Citrix ADC/Gateway VPX 实例与 Workspace UI 和 StoreFront 使用。 -网关服务只能通过适用于 HDX 代理的 Citrix Workspace UI 进行配置-它不为 Citrix StoreFront 提供 HDX 代理功能。
需要 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/网关/StoreFront 部署。 -Citrix Workspace 可在 Citrix Cloud Government 中使用。
能够在没有出站互联网连接的情况下支持空气间隙的 AWS 云/环境。 -本地实例和基于 AWS EC2 的实例均支持由客户管理的 ADC/Gateway(和 StoreFront)部署。 -Air-Gapped AWS 环境无法访问 Citrix Cloud 或 CitCitrix Cloud Government upport,因此网关服务和工作区服务目前不可用。

摘要、建议和领先实践

现在,我们已经审查了一些有助于推动客户对接入层子系统与云服务决策的属性/功能/功能,让我们根据我们之前定义的部署模型的背景来研究顶级决策。

接入层: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 作为工作区的身份提供商的能力中受益。

此部署模型常用于以安全为中心的部署、使用当前本地基础架构(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/网关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 部署。

  • 高可用性:这是生产 环境中最常部署的模型:可以使用上的本机 Citrix HA 模式部署一对 Citrix ADC/Gateway VPX 实例AWS。对于较旧的固件版本,该对部署在同一 AWS 可用区中。从 Citrix ADC 12.1 开始 固件、高可用性对 VPX 设备可以跨可用区 (AZ) 进行部署。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/CVADS 部署的 Citrix ADC VPX 实例接口映射 图 11:用于 CVAD/CVADS 部署的 Citrix ADC VPX 实例接口映射。

跨可用区域的 ADC 高可用性

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

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

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

在上图中,我们可以看到每个 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 的 HA 对的更多信息,请参阅 Citrix docs 并观看 Citrix YouTube 频道中的 这个视频

AWS 上的 Citrix StoreFront

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

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

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

通过利用 Citrix 区域,StoreFront 冗余可以通过将卫星区域分布到具有单个站点的 VPC 中的两个或多个可用区来构建。使用区域是让资源尽可能靠近用户并且具有高可用性的好方法。从属区域包含 StoreFront 服务器、交付控制器和应用程序/桌面资源,在主区域中保留完整的基础架构设置,包括许可证服务器和 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 中托管资源位置的客户使用计算机创建服务来创建、管理和更新 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)来实现。

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

云服务:适用于 Windows 文件服务器的亚马逊 FSX

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

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

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

注意: 由于 FSX 是 Windows 文件服务器,考虑使用此选项的客户应查看 微软的支持声明,了解如何使用 DFS-R 和 DFS-N 来漫游配置文件共享和文件夹重定向共享的信息。

更多云服务选项

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

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

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

图像设计和管理

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

VDA 资源调配和映像管理

在 AWS EC2 上,Citrix 虚拟化系统使用 Citrix 的计算机创建服务 (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 许可证都可以在微软的 SPLA 许可模式下 “租用”,但客户可以通过使用 Linux 作为操作系统来避免这些额外费用。这种模式是在 AWS 上运行的最具成本效益的模式。
  • 服务器 VDI: “服务器 VDI”(虚拟桌面基础架构)模型还使用 Windows Server 操作系统,安装了桌面体验和相关组件后,用户看起来和感觉就像 Windows 桌面操作系统一样。RDSH 角色未与此模型一起安装,因此一个实例一次支持一个用户,有时为用户提供服务器操作系统的提升权限,以便他们可以安装自己的应用程序。与托管共享实例一样,服务器 VDI 实例也可以在共享基础架构上运行,可以使用按需和预留实例定价模式使用,可以使用 GPU 支持的实例类型,并且可以在微软的 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 作为操作系统可以避免大部分复杂性。这种复杂问题大部分是由微软对 Windows 桌面操作系统的许可要求驱动的,这与 Windows Server 不同,微软的 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 没有使用专用实例/主机的微软最终用户许可协议的要求-客户端 VDI(部署 Windows 10 或有时还有 Windows 7)。对于 AWS 上基于 Windows 的工作负载,客户端 VDI 应被视为最后的手段,并且只有在托管共享模型和服务器 VDI 交付模式不可能实现时才部署。

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

AWS 实例账单模型

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

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

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

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

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

注意: 默认情况下,某些较新的 AWS 实例类型不会显示在 Studio 的计算机目录创建向导中(CVAD 或 CVADS)。 用户界面填充来自静态 XML 文件的实例类型,该文件位于交付控制器 (CVAD) 或云连接器 (CVADS) 上。可以修改此 XML 以包括较新的实例类型,但在升级期间(Citrix 启动的 Cloud Connector 更新或客户启动的 Delivery Controller 升级)期间,此文件将被默认值覆盖。有关如何更新可用 AWS 实例类型列表的更多详细信息,请参阅CTX139707。* 要更好地了解实例在 AWS(或任何其他平台)上的通常大小,请参阅此 详细的 AWS LogInvSi 博客。 在这一轮测试(时间点参考)中,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 域控制器、使用面向微软 Active Directory 的 AWS 目录服务或两者的组合。Active Directory 信任也可用于连接两个或多个 AD 森林/域,具体取决于客户的需求。

对于希望最大限度地减少构建和维护功能性 Active Directory 服务所需的管理开销的客户, 面向微软 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 提供了有关这些适用于所有三种部署模型的主题的大量文档。

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

有关升降和班次部署的 Active Directory 要求的详细信息(通过 Citrix Virtual Apps and Desktops LTSR 或 CR 版本使用客户托管会话代理和管理的环境),请参阅 CVAD 技术概述,Active DirectoryCVAD 系统要求,Active Directory 功能级别

会话代理和管理注意事项

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

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

云连接器、交付控制器和资源位置

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

图 13:CVADS 资源位置设计模式,其中包含 VDA 和云连接器的独立子网 图 13:CVADS 资源位置设计模式,其中包含 VDA 和云连接器的独立子网。

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

Citrix Virtual Apps and Desktops 站点设计注意事项

资源位置和区域

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

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

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

AWS 中的配置:计算机创建服务

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

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

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

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

计算机创建服务疑难

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

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

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

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

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

图 14:来自 AWS 快速入门 CloudFormation 模板的 Citrix Virtual Apps and Desktops 服务部署的 “资源位置” 架构/设计模式 图 14:来自 AWS 上的 Citrix Virtual Apps and Desktops 服务部署的 “资源位置” 架构/设计模式 快速入门 CloudFormation 模板。

这种设计模式是 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 网站和 CVADS 资源位置绑定到 特定地区。通过将资源放置在给定区域的多个可用区来实现站点/资源位置的各个组件(例如云连接器、StoreFront 服务器和 ADC/Gateway VPX 实例)的高可用性。
  • 不要过度扩展基础设施跨区域: 虽然在 AWS 上很容易实现,但在扩展任何系统之前,请考虑成本和复杂性与您预期的收益相关的成本和复杂性。你最终有时也会为网络流量和存储流量付费。当流量在某个区域本地时,流量的成本可能微不足道,但是当流量穿越区域或互联网时,成本会增加。

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

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

来自 VPC(区域结构)中任何子网的出站 Internet 访问可以通过多种不同的方式处理,但是一种常见的方法是用 NAT 网关 来为私有子网提供 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 技术:

  • AWS 上的 Citrix Virtual Apps and Desktops 服务 -在 AWS 上部署高度可用的 Citrix Cloud Virtual Apps and Desktops 服务 “资源位置”。
  • 面向 Web 应用程序的 Citrix ADC -在 AWS 上部署高度可用的 Citrix ADC VPX 实例。尽管 使用案例重点略有不同,但此设计模式是有用的,并且与使用 CVAD/CVADS 进行的 Citrix Gateway 部署也相关。Citrix 和 AWS 正在为此特定用例开发额外的快速入门。

我们已经讨论了 “适用于 Web 应用程序的 Citrix ADC” 设计模式如何与 “AWS 上的 Citrix Virtual Apps and Desktops 服务” 模板中的 CVADS 资源位置设计模式相关,因此,让我们分解两者基础的几个基础模板。为简单起见,我们称之为 “CVADS 模板。“

如果我们在 CloudFormation 设计器中打开 CVADS 快速入门模板 ,我们将获得此模板的可视化表示。从此视觉中,我们可以看到此模板使用了三个独立的 “嵌套” 堆栈或模板:

图 15:CloudFormation 设计器中带嵌套堆栈的 CVADS 模板 图 15:CloudFormation 设计器中具有嵌套堆栈的 CVADS 模板。

在图 15 中,CitrixResourceLocation Stack 位于 “顶部”,嵌套在其下面的其他三个堆栈是基础堆栈,由 AWS 管理和维护。

“vpcStack” 模板 将网络基础的大部分放在 CVADS 模板下。vPCStack 负责构建 CVADS 堆栈图的以下组件。所有其他堆栈都在这些资源和参数之上构建: 图 16:vpcStack 示例构建结果 图 16:vpcStack 示例构建结果。

在 vpcStack 之上,还有 rdgwStack 和 AdStack。rdgwStack 模板 制定向 VPCStack 构建的网络提供管理远程控制台访问的基础架构。图 17 中用橙色描述了它。AdStack 模板 与 RDGWStack 并行运行,为系统创建了 Active Directory 基础架构。它包括在 IaaS 实例上创建 AD 以及使用 AWS Active Directory 服务的选项。对于我们的示例设计模式,它用红色构建 AD DS Service 对象: 图 17:vpStack + rdgwStack + AdStack 示例构建结果 图 17:vpStack + rdgwStack + AdStack 示例构建结果。

最后,CitrixResourceLocation Stack(称为三个嵌套堆栈的 “主” 堆栈)在三个基础堆栈之上运行。它负责在 AWS 上创建云连接器和 VDA,并使用 Citrix Cloud API 在 Citrix Cloud 租户中创建资源位置、托管连接、计算机目录和交付组。最终结果?在 AWS 上运行的功能齐全的 Citrix Cloud 资源位置: 图 18:CitrixResourceLocation Stack(加上嵌套堆栈)示例构建结果 图 18:CitrixResourceLocation Stack(加上嵌套堆栈)示例构建结果。

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

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

  • 基础设施即代码是一个强大的概念,可以彻底改变整套系统的设计、构建和维护方式。
  • 在 AWS 的公有云上部署系统时,任何给定解决方案的不同组件都可以通过代码表示,也可以使用 AWS CloudFormation 和其他技术按需构建。
  • 使用 AWS CloudFormation 时,这些组件由堆栈模板表示,并且可以根据需要复制和修改模板以达到所需的结果。
  • 模板可以嵌套,从单个设计模式(模板)构建完整的系统(例如 AWS 上运行完整的 CVADS 资源位置)。
  • AWS 上的 Citrix Virtual Apps and Desktops 服务 快速入门模板基于三个由 AWS 管理/维护的基础模板构建,这些模板都有详尽的文档记录。从以下链接开始,了解有关每个链接的更多信息:

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

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

操作层注意事项

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

按需任务

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

组件 任务 说明
通用 更新知识库 Citrix 团队对与环境相关的问题进行故障排除时,他们将确定问题的解决方案。应为每个问题创建 KBA,以帮助支持未来的故障排除活动。
Citrix Virtual Apps and Desktops 修改图像 图片将根据需要进行更新以支持请求。更新可能每月进行,但可能需要更频繁的更新才能进行测试。
Citrix Virtual Apps and Desktops 发布图片 修改图像时,会对其进行测试和发布。
AWS 验证实例启动 当通过 MCS 启动新实例时,请验证实例是否已在 AWS 控制台中创建,以及给定 VPC 的池中是否有可用的 IP。如果 VPC 池中没有可用的 IP,则不会创建 MCS 置备的计算机。
AWS 验证本地图像的功效 从任何本地映像创建的实例在用于更新生产实例之前,应对其可启动性和可行性进行测试。
AWS 修改IAM 用户/组权限 根据需要,应审查 IAM 用户和组权限,以减少具有管理访问权限的用户数量,并实施 “最低权限” 方法。
AWS 修改安全组 根据需要,将对安全组进行审查,以授予或删除对来自不同 IP 或 IP 范围的不同流量协议的访问权限。将修改入口和出口规则以实施网络流量封锁。
AWS 和 Citrix Virtual Apps and Desktops 更新计算机目录中的计算机 根据需要,更新计算机映像以包含任何必要的修改。必须为修改后的映像创建新 AMI,并用于更新计算机目录。有关详细信息,请参阅本文档的更新和升级过程部分。
AWS 和 Citrix Virtual Apps and Desktops 将更新回滚到计算机目录 根据需要,如果必须回滚计算机映像,则可以使用具有最后一个已知工作配置的先前 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 虚拟机电源检查 验证是否已打开适当数量的空闲桌面和应用程序服务器并向交付控制器注册,以确认用户工作负载的可用性。
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)分配、许可、网络带宽。根据需要购买软件和/或许可证并构建额外的服务器。注意: 执行容量评估的建议包含在 Citrix Virtual Apps and Desktops 最佳实践指南的监视部分中的决策:容量管理中。
通用 查看提升的权限访问 查看哪些用户和组对环境具有提升的权限,并评估是否需要持续提升的访问权限。删除任何不再需要这些管理权限的帐户。主要仅限用于分配提升权限的 IAM 用户和角色,并严格限制对个人用户、本地或根账户的访问权限。

每年定期任务

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

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

来源

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

AWS 上 Citrix Virtual Apps and Desktops 的参考体系结构