产品文档
Citrix Tech Zone
查看 PDF

参考架构：Citrix DaaS - Azure

May 12, 2023
Author: Loay Shbeilat
Special thanks: Nitin Mehta

简介

本指南有助于了解 Microsoft Azure 上的 Citrix DaaS 的架构和部署模型。

Citrix Cloud 和 Microsoft Azure 的组合使得能够以更高的敏捷性和弹性启动新的 Citrix 虚拟资源，并随着需求的变化调整使用情况。Azure 上的虚拟机支持 Citrix DaaS 部署所需的所有控制和工作负载组件。Citrix Cloud 和 Microsoft Azure 具有通用控制平面集成，这些集成可建立全球运营的标识、治理和安全性。

本文档还提供了有关客户环境的必备条件、体系结构设计注意事项和部署指南的指导。 本文档重点介绍了以下五个关键架构原则的设计决策和部署注意事项：

  • 运营-运营包括各种各样的主题，如映像管理、服务监视、业务连续性、支持等。有各种工具可用于协助自动化操作，包括 Azure PowerShell、Azure CLI、ARM 模板和 Azure API。

  • 身份-Azure 整个画面的基石之一是个人的身份及其基于角色的访问权限 (RBAC)。Azure 身份通过 Azure Active Directory (Azure AD) 和 Azure AD 域服务进行管理。客户必须决定采用哪种方式进行身份集成。

  • 治理-治理的关键是建立与 Azure 资源的规划、体系结构、获取、部署和操作管理相关的策略、流程和过程。

  • 安全-Azure 提供各种可配置的安全选项和控制这些选项的功能，以便客户可以自定义安全性以满足其组织部署的独特要求。本部分有助于了解 Azure 安全功能如何帮助您满足这些要求。

  • 连接- 将 Azure 虚拟网络与客户的本地/云网络连接称为混合网络。本节介绍了网络连接和网络服务路由的选项。

计划

通过 Azure 交付 Citrix Virtual Apps and Desktops 的三种最常见方案是：

  • 使用 Citrix Cloud 进行绿地部署，在 Azure 中提供资源位置。此方案通过 Citrix DaaS 交付，当客户更喜欢使用订阅模式并将控制平面基础架构外包给 Citrix 时使用。
  • 将本地部署扩展到 Azure 中。在这种情况下，客户具有当前的本地控制层，并希望将 Azure 添加为 Citrix 资源位置，以便进行新的部署或迁移。
  • 举起然后移动。在此方案中，客户可以使用 Citrix ADC 和 StoreFront 聚合来自多个站点的资源，将其 Citrix 管理基础架构部署到 Azure 中，并将 Azure 视为站点。

本文档重点介绍 Citrix Cloud 部署模型。客户可以根据其组织需求规划和采用这些服务：

Citrix DaaS

Citrix DaaS 简化了 Citrix 技术的交付和管理，帮助客户扩展现有的本地软件部署或百分之百地迁移到云端。提供对 Windows、Linux 和 Web 应用程序以及 Windows 和 Linux 虚拟桌面的安全访问。跨多个资源位置集中管理应用和桌面，同时保持卓越的终端用户体验。

Citrix Virtual Desktops Essentials 服务

Citrix 和 Microsoft 客户有更多选择在其组织内部署 Windows 10 Enterprise。Citrix Virtual Desktops Essentials 服务可为偏爱 Microsoft Azure 云解决方案的客户加速 Windows 10 Enterprise 迁移。这使已按用户授予 Windows 10 企业版（当前企业分支）许可的客户可以选择从 Azure 提供高性能 Windows 10 企业版虚拟桌面体验。

Citrix Virtual Apps Essentials 服务

新的应用程序虚拟化服务 Citrix Virtual Apps Essentials 将 Citrix Cloud 平台的强大功能和灵活性与 Microsoft Azure RemoteApp 的简单、规范性且易于使用的愿景相结合。Citrix Virtual Apps Essentials 通过将后端基础架构迁移到云端，在不牺牲管理或最终用户体验的情况下简化应用程序交付，从而提供卓越的性能和灵活性。

概念参考架构

此概念体系结构提供了在 Azure 中部署 Citrix Cloud 资源位置的常用指南，将在以下各节中讨论。

Azure-RA-Image-1

图-1：Citrix Cloud 概念参考体系结构

请参阅设计指南，了解在 Microsoft Azure 上交付 Citrix DaaS 的可扩展性和经济性

operations

在运营主题领域，本指南更深入地探讨了基础服务的工作空间环境要求和层次结构的规划。最上层是订阅、资源组和区域设计注意事项。其次是有关虚拟机存储、用户配置文件存储和主映像管理/配置的常见问题。还提供了有关使用 AutoScale 优化预留实例和规划业务连续性/灾难恢复的指南。

命名约定

在 Microsoft Azure 中命名资源非常重要，因为：

  • 大多数资源在创建后无法重命名
  • 特定资源类型有不同的命名要求
  • 一致的命名约定使资源更易于查找，并且可以指示资源的角色

成功使用命名约定的关键是在应用程序和组织中建立并遵循命名约定。

在命名 Azure 订阅时，详细名称可以清楚地了解每个订阅的上下文和目的。在具有多个订阅的环境中工作时，遵循命名约定可以提高清晰度。

推荐的订阅命名模式是：

变量 示例 说明
[系统] CTX (Citrix)、CORE (Azure) 资源支持的产品、应用程序或服务的三个字母标识符。
[角色] XAW (XenApp Worker)、VDA (Virtual Delivery Agent)、CC (Cloud Connector)、CVA (Citrix Virtual Apps) 服务子系统的三个字母标识符。
[环境] D、T、P（开发、测试或产品） 标识资源的环境
## 01, 02 对于具有多个命名实例（Web 服务器等）的资源。
[地点] 吴 (美国西部), 欧盟 (美国东部), SCU (美国中南部) 标识资源部署到的 Azure 区域

在 Azure 中命名资源时，请使用常用前缀或后缀来标识资源的类型和上下文。虽然有关类型、元数据、上下文的所有信息都可以通过编程方式获得，但应用常用词缀可以简化视觉识别。将词缀纳入命名约定时，必须明确指定词缀是位于名称的开头（前缀）还是结尾（后缀）。

定义明确的命名方案可识别 Azure 资源的系统、角色、环境、实例计数和位置。可以使用 Azure 策略强制执行命名。

服务 Scope（范围） 建议的模式 示例
订阅 全局 [System][Environment]##[Location]-sub WSCD01scu-sub
资源组 全局 [System]-[Role]-[Environment]##-[Location]-rg CTX-Apps-P01-CUS-rg
虚拟网络 资源组 [System][Environment]##[Location]-vnet CTXP01cus-vnet
子网 父级 VNET [Descriptive Context] DMZ - 10.0.1.0/24 Infrastructure - 10.0.2.0/24
存储帐户 资源组 [System][Role][Environment]##[Location]注意：必须是小写字母数字 ctxinfd01scu
集装箱 存储帐户 [Descriptive Context] vhds
虚拟机 资源组 [System][Role][Environment]##[Location]注意：必须不超过 15 个字符。 CTXSTFD01scu
网络接口 资源组 [vmname]-nic# CTXSTFD01scu-nic1
公共 IP 资源组 [vmname]-pip CTXSTFD01scu-pip
虚拟网络网关 虚拟网络 [System][Environment]##[Location]-vng WSCD01scu-vng
本地网络网关 资源组 [System][Environment]##[Location]-lng WSCD01scu-lng
可用性集 资源组 [System][Role]-as CTXSTF-as
负载平衡器 资源组 [System][Role]-lb CTXNSG-lb
工作区 订阅 [System][Environment]-analytics CTXP-analytics
标记 资源 [Descriptive Context] Finance
密钥保管库 订阅 [System][Environment]-vault CTXP-vault

订阅

选择订阅模式是一项复杂的决定，涉及了解客户在 Citrix 部署内外的 Azure 足迹的增长。即使 Citrix 部署很小，客户仍可能有大量其他资源正在对 Azure API 进行大量读取/写入，这可能会对 Citrix 环境产生负面影响。相反的情况也是如此，其中许多 Citrix 资源可能会消耗过多的可用 API 调用，从而降低了订阅中其他资源的可用性。

单一订阅工作区模型

在单个订阅模式中，所有核心基础结构和 Citrix 基础结构位于同一订阅中。对于需要最多 2,500 个 Citrix VDA（可以是会话、池 VDI 或永久 VDI）的部署，建议使用这种配置。限制可能会发生变化，请查看以下内容以了解最新的 VDA 限制。请参阅以下博客，了解单个订阅中最新的启动-关闭规模数字，

图2:Azure单一订阅工作区模型Azure-RA-Image-2

多订阅 Workspace 模型

在此模型中，核心基础架构和 Citrix 基础结构处于单独的订阅中，以管理大型部署中的可扩展性。通常，具有多区域基础结构设计的企业部署会被分成多个订阅，以防止达到 Azure 订阅限制。

Azure-RA-Image-3

示意图 3：Azure 多订阅 Workspace 模型

以下问题提供指导，帮助客户理解 Azure 订阅选项和规划资源。

组件 要求
Azure 订阅是否只包含 Citrix 资源？ 确定 Azure 订阅是否将用于专用 Citrix 资源，或者是否将与其他系统共享 Citrix 资源。
单订阅还是多订阅部署？ 通常，多订阅部署适用于较大的部署，在这种情况下，单一订阅限制是一个问题，需要更精细的安全控制。
可能会达到哪些 Azure 限制？一个资源组中有多少资源？ 资源组有限制，并且对每个 VM 资源，Machine Creation Services (MCS) 需要 2 个或 3 个磁盘。在规划解决方案时查看Azure 订阅限制。
Azure 订阅的 CVAD 服务原则需要哪些权限？ Citrix DaaS 需要在订阅中创建资源组和资源。例如，如果无法授予服务原则对订阅的完全访问权限，则需要向其授予对预先创建的资源组的 Contributor 访问权限。
开发和测试环境是否会在独立于生产环境的订阅中创建？ 将开发和测试订阅与生产环境隔离后，可以在隔离的环境中应用和更改全局 Azure 服务，并降低资源利用率。这种做法对安全性、合规性和订阅性能都有好处。为这些环境创建单独的订阅确实会增加映像管理的复杂性。应根据客户的需求来考虑这些折衷方案。

Azure 区域

Azure 区域是在延迟定义的外围内部署的一组数据中心，并通过专用的区域低延迟网络进行连接。Azure 为客户提供了在需要的地方部署应用程序的灵活性。Azure 在全球 59 个地区普遍可用，并宣布计划在 2022 年底再推出 19 个区域。

地理位置是一个离散的市场，通常包含两个或多个 Azure 区域，可以保留数据驻留和合规性界限。地理位置允许具有特定数据驻留和合规性需求的客户保持其数据和应用程序的关闭。

可用区是 Azure 区域中物理上独立的位置。每个可用区由一个或多个配备独立电源、冷却和网络的数据中心组成。可用区允许客户运行具有高可用性和低延迟复制的任务关键型应用程序。为确保弹性，在所有启用区域中至少有三个独立的区域。

在选择您的区域时，请考虑这些因素。

组件 要求
合规性和数据驻留 客户是否有特定的合规性或数据驻留要求？Microsoft 可以在给定地理位置内的区域之间复制客户数据，以实现数据冗余或其他操作目的。例如，如果发生重大数据中心灾难，Azure 全局冗余存储 (GRS) 会在同一地理中的两个区域之间复制 Blob 和表数据，以增强数据持久性。某些 Azure 服务不允许客户指定将部署该服务的区域。除非另有说明，这些服务可以将客户数据存储在 Microsoft 的任何数据中心中。查看Azure 区域地图网站以获取最新更新。
服务可用性 查看暂定区域内的服务可用性。按区域划分的服务可用性有助于客户确定某个区域内可用的服务。尽管蓝色e 服务可以在给定区域受支持，但并非所有服务功能都在主权云中可用，例如 Azure 政府、德国和中国。
确定 Citrix 部署的目标 Azure 区域。 查看 Azure 区域与用户和客户数据中心的接近程度。
是否需要多个 Azure 区域？ 多个 Azure 区域通常出于以下高级原因考虑：-接近应用程序数据或最终用户-用于业务连续性和灾难恢复的地理冗余-Azure 功能或服务的可用性

可用性集

可用性集是一种逻辑分组功能，可以在 Azure 中使用，以确保放置在可用性集中的虚拟机资源在 Azure 数据中心内部署时彼此隔离。Azure 确保放置在可用性集中的虚拟机跨多个物理服务器、计算机架、存储单元和网络交换机运行。如果发生硬件或 Azure 软件故障，则只有一部分 VM 会受到影响，整个应用程序将保持运行状态并保持对客户可用。当客户想要构建可靠的云解决方案时，可用性集是一项必不可少的功能。

Citrix 部署的每个组件都应位于其自己的可用性集中，以最大限度地提高 Citrix 的整体可用性。例如，Cloud Connector 应使用单独的可用性集，另一个可用性集用于 Citrix 应用程序交付控制器 (ADC)、StoreFront 等。

可用性集优化后，下一步就是在可用性集中围绕虚拟机停机时间建立弹性。这可以最大限度地减少/消除 Microsoft 重新启动或重新部署虚拟机时的服务停机时间。这也可以扩展到计划的维护事件。您可以使用两个功能来提高整体服务的可靠性。

这两个功能无法防止计划外维护/崩溃。

  • Azure 计划维护
  • Azure 计划事件

Azure 计划维护

Azure会定期执行更新,以提高Azure中主机基础结构的可靠性,性能和安全性。如果维护需要重新启动，Microsoft 将发送通知。使用 Azure 计划内维护，可以捕获这些通知，并按照客户的时间表（而不是 Microsoft 的时间表）主动采取行动。

通过向每个层的服务所有者发送电子邮件通知（用于手动干预），利用计划维护功能，并构建运行手册以自动执行服务保护。

Azure 计划事件

Azure 预设事件是一项 Azure 元数据服务，它以编程方式向应用程序发出通知，以提醒即时维护。它提供有关即将发生的维护事件（例如重新启动）的信息，以便应用程序管理员可以为中断做好准备并限制中断。虽然这听起来像是计划中的维护，但事实并非如此。关键区别在于，这些事件是为计划内维护而触发的，有时是非计划的维护。例如，如果 Azure 正在执行主机修复活动，需要在短时间内移动 VM。

这些事件以编程方式消费，并将提前发出以下通知：

  • 冻结— 15 分钟
  • 重启— 15 分钟
  • 重新部署— 10 分钟

灾难恢复 (DR)

Azure 可以为希望立即从云采用中获得价值的 Citrix 客户提供极具成本效益的灾难恢复解决方案。部署模型拓扑决定了灾难恢复解决方案的实施。

扩展架构

在此拓扑下，管理基础结构仍保留在本地，但工作负载部署到 Azure。如果无法访问本地数据中心，现有已连接的用户将保持连接，但由于管理基础结构不可用，因此将无法建立新连接。

要保护管理基础架构，请预配置 Azure 站点恢复以将管理基础结构恢复到 Azure 中。这是一个手动过程，一旦恢复，您的环境就可以运行。此选项不是无缝的，无法恢复 ADC VPX 之类的组件，但是对于恢复时间目标 (RTO) 更灵活的组织，它可以降低运营成本。

托管体系结构

部署此拓扑时，Citrix 管理基础结构将部署到 Azure 中，并将其视为一个单独的站点。这在发生站点故障时提供了与本地部署的功能隔离。使用 Citrix ADC 和 StoreFront 聚合资源并为用户提供生产资源和灾难恢复资源之间近乎即时的故障切换。

Azure 中存在 Citrix 基础结构意味着在用户访问其核心 Workspace 之前，无需调用手动进程，也无需恢复任何系统。

云服务架构

使用 Citrix Cloud 时，Azure 只会变成另一个资源位置。此拓扑提供了最简单的部署，因为管理组件由 Citrix 即服务托管，并且无需部署重复的基础结构来支持它，即可实现灾难恢复工作负载。发生灾难时故障切换期间的用户体验可以是无缝的。

下表中的项目可帮助客户进行 DR 计划：

组件 要求
Citrix 环境的 RTO 和 RPO 要求是什么？ RTO-灾难后必须恢复业务流程的目标持续时间和服务级别。RPO-中断期间在该期间丢失的数据量超过业务连续性计划的最大允许阈值或“容忍”之前可能经过的时间间隔。
当在部署 Azure 虚拟机应用程序的整个区域发生服务中断时，预期结果是什么？ 应按照客户的 RTO 和 RPO 来审查这些选项以进行灾难恢复。Azure 中 Citrix 环境的灾难恢复可以通过 Azure 站点恢复、被动辅助站点和主动站点 Azure 站点来解决。恢复仅支持服务器操作系统（Citrix 基础结构和服务器 VDA）。不支持客户端操作系统（例如，使用 ARM 模板创建的持久性桌面）。此外，必须使用恢复任务重新创建 MCS（服务器或客户端 VDA）创建的计算机目录。

资源组

Azure 中的资源组 (RG) 是逻辑组中的资产集合，用于轻松甚至自动预配、监视和访问控制，并更有效地管理其成本。在 Azure 中使用 RG 的好处是将属于应用程序的相关资源分组在一起，因为它们共享从创建到使用以及最终取消置备的统一生命周期。

成功设计资源组的关键在于了解其中包含的资源的生命周期。

资源组在创建时与计算机目录绑定，以后无法添加或更改。要向计算机目录中添加额外的资源组，必须删除并重新创建计算机目录。

映像管理

映像管理是创建、升级和分配在开发、测试和生产环境中一致应用的映像的过程。在开发映像管理流程时，应考虑以下几点：

按需配置

客户需要确定是否使用 MCS 来管理 Azure 非持久性计算机或创建自己的 Azure Resource Manager (ARM) 模板。当客户使用 MCS 创建计算机目录时，Azure 按需置备功能可降低存储成本，提供更快的目录创建和更快的虚拟机 (VM) 电源操作。使用 Azure 按需置备时，只有在置备完成后，Citrix DaaS 启动开机操作时才会创建 VM。虚拟机仅在运行时才在 Azure 门户中可见，而在 Citrix Studio 中，无论电源状态如何，所有虚拟机都是可见的。通过 ARM 模板或 MCS 创建的计算机可以由 Citrix 使用 Citrix Studio 中的 Azure 主机连接进行电源管理。

存储帐户容器

客户需要决定存储源（或黄金）映像的组织结构，以便使用 Citrix 计算机创建服务 (MCS) 创建虚拟机。Citrix MCS 映像可以来自快照、托管或非托管磁盘，并且可以驻留在标准或高级存储上。非托管磁盘可通过通用存储帐户进行访问，并作为 VHD 存储在 Azure Blob 存储容器中存储。容器是可用于分隔生产、测试和开发映像的文件夹。

映像复制

客户需要确定跨区域复制映像的适当过程，以及如何在整体映像管理策略中使用 Citrix App Layering 技术。PowerShell 脚本可以与 Azure 自动化一起使用来计划映像复制。有关 Citrix App Layering 的更多信息可在此处找到，但请记住，弹性分层需要不驻留在 Azure 文件中的 SMB 文件共享。有关支持弹性分层的受支持的 SMB 共享技术，请参阅文件服务器部分。

文件服务器技术

Azure 提供了多种文件服务器技术，可用于存储 Citrix 用户数据、漫游配置文件信息或作为 Citrix 分层共享的目标。这些选项包括以下内容：

  • 独立文件服务器
  • 使用存储副本的文件服务器
  • 使用直接存储空间 (S2D) 横向扩展文件服务器 (SOFS)
  • 分布式文件系统 — 复制 (DFS-R)
  • 来自 Azure 市场的第三方存储设备（例如 NetApp 等）

客户应选择最能满足其业务需求的文件服务器技术。下表概述了每种不同文件服务技术的一些优势和注意事项。

选项 优势 注意事项
独立文件服务器 众所周知并经过测试。与现有的备份/恢复产品兼容 单点故障。没有数据冗余。每月修补中断，以分钟为单位。
使用存储副本的文件服务器 块级复制。SMB 3.0。存储不可知（SAN、云、本地等）。提供同步和异步复制。建议在需要多区域访问时使用 需要手动故障切换。使用 2 倍磁盘空间。手动故障切换仍有停机时间，以分钟为单位。DNS 依赖关系。
存储空间直接上的 SOFS 高度可用。多节点和多磁盘高可用性。向上扩展或向外扩展。SMB 3.0 和 3.1。计划内和计划外维护活动期间的透明故障切换。建议用于 Azure 中的用户配置文件存储 使用 2-3 倍的磁盘空间。供应商可能会限制第三方备份软件支持。不支持多区域部署
分布式文件系统 — 复制 经验证的基于文件的复制技术。支持 PowerShell 基于域。无法在主动-主动配置中部署。
第三方存储应用程序 重复数据消除技术。更好地利用存储空间。 额外的费用。专利管理工具。

推荐的文件服务器虚拟机类型通常为 DS1、DS2、DS3、DS4 或 DS5，并根据客户的使用要求进行适当的选择。为获得最佳性能，请确保选择了高级磁盘支持。额外的指导可以在Microsoft Azure文档中找到。

基础设施成本管理

有两种技术可用于降低 Azure 中 Citrix 环境的成本，即预留实例和 Citrix 自动缩放的成本。

预留实例

与 Windows 和 Linux 虚拟机 (VM) 的即用即付价格相比，Azure 虚拟机预留实例 (RI) 可显著降低成本，最多可降低 72%。如果客户将从 Azure RI 获得的成本节约与 Azure 混合权益的附加值结合起来，他们最多可以节省 80% 的费用。80% 的计算基于 Windows 服务器的三年 Azure 预留实例承诺，与正常的即用即付费率相比。

虽然 Azure 预留实例需要预先承诺计算容量，但它们还提供了随时交换或取消预留实例的灵活性。预留仅涵盖虚拟机计算成本。它不会降低任何额外的软件、网络或存储费用。这对 Citrix 基础架构和使用案例（在工作时间和非工作时间）所需的最低容量很有用。

Citrix AutoScale 功能还支持预留实例以进一步降低成本-您现在可以使用 AutoScale 在云中进行突发。在交付组中，您可以标记需要自动扩展的计算机，并排除您的预留实例（或本地工作负载）-您可以在此处找到更多信息：将 AutoScale 限制为交付组中的某些计算机。

Citrix Autoscale

AutoScale 是 Citrix DaaS 独有的一项功能，可提供一致的高性能解决方案来主动对计算机进行电源管理。它旨在平衡成本和用户体验。Autoscale 将弃用的 Smart Scale 技术集成到 Studio 电源管理解决方案中。

计算机类型 基于时间表 基于负载 基于加载和计划
托管已发布应用程序或托管共享桌面的服务器操作系统计算机（服务器 VDI） 支持 支持 支持
托管静态持久（专用）VDI 桌面的桌面操作系统计算机 支持。在计算机关闭电源期间（例如，在工作时间之后），用户可以通过 Citrix Receiver 触发计算机打开电源。您可以设置 Autoscale 的关机延迟，这样 Autoscale 就不会在用户建立会话之前自动关闭计算机电源。 仅支持未分配的计算机。 仅支持未分配的计算机。
桌面操作系统-托管的计算机-随机非持久 VDI 桌面（池 VDI 桌面） 支持 支持。使用会话计数扩展指标并将最大会话数设置为 1。 支持。使用“会话计数”扩展指标，并将计算机的最小数量设置为 1。

Azure-RA-Image-4

图表 4：Citrix 自动缩放流

您可以在此处阅读有关 Citrix 自动缩放的更多信息。

优化最终用户体验

优化最终用户体验包括在最终用户对响应能力的看法与保持预算范围内的业务需求之间取得平衡。本节讨论了围绕提供适合业务和最终用户的环境的设计概念和决策。

定义用户 Workspace

查看以下高级别问题，以更好地了解现有用例及其最终用户所需的资源。

主题 问题
用户数 环境中预期有多少用户？评估阶段是否确定了合适的 VDI 模型？（虚拟应用程序或虚拟桌面）
用例 最终用户将使用哪些类型的应用程序？应用程序的 VDA 要求是什么？如何以最佳方式交付应用程序？（虚拟应用程序与虚拟桌面）
用户组工作时间 用户何时访问环境？高峰时段是什么？一整天的预期消耗量是多少？（用户在特定时段的使用情况有助于确定扩展自动化和 Azure 预留实例购买的工作空间要求。）
位置 最终用户在哪里？应该跨多个区域部署工作空间，还是仅在单个区域部署工作空间？
用户和应用程序数据 用户和应用程序数据存储在哪里？数据是仅包含在 Azure 中，还是仅包含在本地，还是两者混合？访问用户数据的最大容许延迟是多少？

Azure 虚拟机实例类型

每个 Citrix 组件在 Azure 中使用关联的虚拟机类型。每个可用 VM 系列都映射到特定类别的工作负载（通用型、计算优化型等），其大小控制分配给 VM 的资源（CPU、内存、IOPS、网络等）。

大多数 Citrix 部署使用 D 系列和 F 系列实例类型。D 系列通常用于 Citrix 基础架构组件，有时用于用户工作负载，如果用户需要超出 F 系列实例类型中的额外内存，则用于用户工作负载。F 系列实例类型在用户工作负载中是最常见的，因为它们的处理器速度更快，能够带来响应速度。

为什么 D 系列还是 F 系列？从 Citrix 的角度来看，大多数基础架构组件（Cloud Connector、StoreFront、ADC 等）都使用 CPU 来运行核心进程。这些虚拟机类型的 CPU 与内存之比平衡，托管在统一硬件上（不同于 A 系列），以获得更一致的性能并支持高级存储。当然，客户可以而且应该调整他们的实例类型以满足他们的需求和预算。

客户基础架构中组件的大小和数量将始终取决于客户的需求、规模和工作负载。但是，使用 Azure，我们可以动态扩展和按需扩展！对于注重成本的客户，从小规模开始并扩大规模是最好的方法。Azure VM 在更改大小时需要重新启动，因此只能在计划的维护时段内并根据既定的更改控制策略计划这些事件。

如何扩展或扩展

应查看以下高级问题，以更好地了解客户的用例及其最终用户所需的资源。这也有助于他们提前计划自己的工作量。

如果每个用户每小时的成本需要最低，并且如果实例出现故障，则可以容忍更大的影响，则可以扩展最佳。当需要最大限度地减少单个实例故障的影响时，最好使用横向扩展。下表提供了不同 Citrix 组件的一些示例实例类型。

组件 推荐的实例类型
Delivery Controller、Cloud Connector 带有 Premium SSD 存储的标准 DS2_v2 或 DS2_v3
向上扩展服务器操作系统用户工作负载 与其他实例相比，带有虚拟应用程序的 Standard_F16s_v2 VM 的每用户/小时成本最低。与其他实例相比，Standard_DS5_v2 虚拟机在成本上也具有竞争力
横向扩展服务器操作系统用户工作负载 Standard_F4_v2 和 Standard_F8_v2 实例支持较少的用户数，但由于用户容器大小较小，因此电源管理操作更加灵活。这样可以更有效地解除计算机的分配，从而节省按需付费实例的成本。此外，横向扩展时故障域会更小。
桌面操作系统用户工作负载 标准 F2_v2 具有最低的双核成本，并且与 Windows 10 一起运行良好。

最新的实例类型研究旨在提供有关该领域的深刻见解，我们强烈建议您阅读。在所有情况下，客户都应评估实例类型及其工作负载。

对于图形密集型工作负载，请考虑使用 NVv4 系列虚拟机。它们由 AMD EPYC 7002 处理器和虚拟化的 Radeon MI25 GPU 提供支持。这些虚拟机已针对 VDI 和远程可视化进行了优化和设计。借助分区 GPU，NVv4 以最优的价格为需要较小 GPU 资源的工作负载提供合适的大小。另外，NVv3 系列经过优化，专为使用 OpenGL 和 DirectX 等框架进行远程可视化、流媒体、游戏、编码和 VDI 场景而设计。这些虚拟机由 NVIDIA Tesla M60 GPU 提供支持。有关更多的 GPU 选项，请查看 Azure 的其他产品。

虽然向上扩展通常是降低成本的首选模式，但 Autoscale 可以从较小的实例（每台主机 15 到 20 个会话）中受益。较小的实例托管的用户会话数少于较大的实例。因此，如果实例较小，AutoScale 将计算机置于耗尽状态的速度要快得多，因为注销最后一个用户会话所需的时间更短。因此，AutoScale 更快地关闭较小实例的电源，从而降低成本。您可以在官方文档中阅读有关 AutoScale 实例大小注意事项的更多信息。

存储

就像任何其他计算机一样，Azure 中的虚拟机使用磁盘作为存储操作系统、应用程序和数据的位置。所有 Azure 虚拟机都至少有两个磁盘：一个 Windows 操作系统磁盘和一个临时磁盘。操作系统磁盘是从映像创建的，操作系统磁盘和映像都作为虚拟硬盘 (VHD) 存储在 Azure 中。虚拟机还可能附加额外的磁盘作为数据磁盘，也可以存储为 vHD。

Azure 磁盘旨在提供企业级持久性。创建磁盘时可以选择三个存储性能层：Premium SSD 磁盘、标准 SSD 和标准 HDD 存储，磁盘可以是托管的，也可以是非托管的。托管磁盘是默认磁盘，不受存储帐户限制（如非托管磁盘）的约束。

Microsoft 建议使用托管磁盘而不是非托管磁盘。非托管磁盘应仅在例外情况下考虑。标准存储（HDD 和 SSD）包括必须考虑的事务成本（存储 I/O），但每个磁盘的成本较低。Premium Storage 没有交易成本，但每个磁盘的成本更高，可提供更好的用户体验。

除非使用可用性集，否则磁盘不提供 SLA。Citrix MCS 不支持可用性集，但应包含在 Citrix Cloud Connector、ADC 和 StoreFront 中。

身份

本节重点介绍身份控制、工作区用户规划和最终用户体验。主要的设计考虑因素是管理 Azure 和 Citrix Cloud 租户中的身份。

Microsoft Azure Active Directory (Azure AD) 是一种身份识别和访问管理云解决方案，提供目录服务、身份治理和应用程序访问管理。创建 Azure 订阅时，单个 Azure AD 目录会自动与该目录相关联。

每个 Azure 订阅都与 Azure AD 目录建立信任关系，用于对用户、服务和设备进行身份验证。多个订阅可以信任同一个 Azure AD 目录，但订阅只信任单个 Azure AD 目录。

Microsoft 的身份解决方案涵盖本地和基于云的功能，创建单一用户身份，用于对所有资源（无论身在何处）进行身份验证和授权。这个概念被称为混合身份。使用 Microsoft 解决方案的混合身份有不同的设计和配置选项，在某些情况下，可能很难确定哪种组合最能满足组织的需求。

常见的身份设计注意事项

通常，将客户 Active Directory 站点扩展到 Azure 使用 Active Directory 复制来提供与 Citrix Workspace 的身份和身份验证。常见的步骤是使用 AD Connect 将用户复制到 Azure Active Directory，这为您提供了 Windows 10 所需的基于订阅的激活。

建议将本地 Active Directory 域服务扩展到 Azure 虚拟网络子网以获得全部功能和可扩展性。 Azure 基于角色的访问控制 (RBAC) 有助于提供对 Azure 资源的精细访问管理。过多的权限可能会向攻击者公开和说明攻击者。权限太少意味着员工无法高效地完成工作。使用 RBAC，管理员可以为员工提供他们所需的确切权限。

身份验证

核心 Citrix 功能需要域服务（AD DS 或 Azure AD DS）。RBAC 是基于 Azure Resource Manager 构建的授权系统，可提供 Azure 中资源的精细访问管理。RBAC 允许您精细地控制用户拥有的访问级别。例如，您可以将一个用户限制为仅管理虚拟网络，而将另一个用户限制为管理资源组中的所有资源。Azure 包含几个您可以使用的内置角色。

Citrix Workspace、Citrix DaaS 和 Citrix ADC/StoreFront 身份验证支持 Azure AD 身份验证。对于具有 Azure AD 的完整 SSON，必须使用 Citrix 联合身份验证服务 (FAS) 或 Azure AD DS（适用于核心域服务）。

Citrix FAS 支持 Citrix Workspace 中的 DaaS 单点登录 (SSO)。如果您使用以下身份提供商之一，通常会采用 Citrix FAS：

  • Azure Active Directory
  • Okta
  • SAML 2.0
  • Citrix Gateway

Active Directory 和 Azure Active Directory 结果

  • Azure Active Directory 预配的租户
  • 映射到内置或自定义 Azure 角色的 Azure RBAC 所需组织角色的列表
  • 所需的管理员访问级别列表（帐户、订阅、资源组等）
  • 向新用户授予Azure的访问权限/角色的过程
  • 为特定任务的用户分配 JIT（及时）提升的过程

以下是命名空间布局和身份验证流程的示例体系结构。

Azure-RA-Image-5

图表-5：命名空间布局和身份验证流的体系结构

Citrix Cloud 管理 + Azure AD

默认情况下，Citrix Cloud 使用 Citrix 身份提供程序来管理所有访问 Citrix Cloud 的用户的身份信息。客户可以将其更改为使用 Azure Active Directory (AD)。 通过将 Azure AD 与 Citrix Cloud 配合使用，客户可以：

  • 使用他们自己的 Active Directory，这样他们就可以控制审核和密码策略，并在需要时轻松禁用帐户。
  • 配置多因素身份验证以提高安全级别，防止出现被盗登录凭据的可能性。
  • 使用带标志的登录页面，以便您的用户知晓自己正在正确的位置登录。
  • 使用您选择的身份提供程序的联合，其中包括 ADFS、Okta 和 Ping。

Citrix Cloud 包含一个 Azure AD 应用程序，该应用程序允许 Citrix Cloud 无需登录活动的 Azure AD 会话即可与 Azure AD 进行连接。Citrix Cloud 管理员登录允许在客户 Citrix Cloud 租户中使用 Azure AD 身份。

  • 确定 Citrix Cloud 管理员是使用 Citrix 身份还是 Azure AD 访问 Citrix Cloud，URL 将遵循格式https://citrix.cloud.com/go/{Customer Determined}
  • 将 Azure AD 身份验证的身份验证 URL 识别到 Citrix Cloud

治理

Azure 治理是一组概念和服务，旨在大规模管理各种 Azure 资源。这些服务提供了以逻辑方式组织和构建订阅的能力，以及创建、部署和可重复使用 Azure 本机资源包。本主题的重点是建立与 Azure 资源的规划、体系结构、获取、部署、操作和管理相关的策略、流程和程序。

Citrix Cloud 管理员登录

确定 Citrix Cloud 管理员是使用他们的 Citrix 身份、Active Directory 身份还是 Azure AD 来访问 Citrix Cloud。通过 Azure AD 集成，管理员可以在 Citrix Cloud 中进行多重身份验证。确定 Azure AD 身份验证到 Citrix Cloud 的身份验证 URL。URL 遵循以下格式https://citrix.cloud.com/go/{Customer Determined}。

RBAC 权限和委派

使用 Azure AD 客户可以使用 Azure 资源的基于角色的访问控制 (RBAC) 来实施其治理策略。应用这些权限的主要工具之一是资源组的概念。将资源组视为共享生命周期和管理所有权的 Azure 资源捆绑。

在Citrix环境中,这些内容的组织方式应允许在团队之间进行适当的委派,并促进最低权限的概念。一个很好的例子是，Citrix Cloud 部署使用从 Azure 市场预配置的 Citrix ADC VPX 进行外部访问。尽管 NetScaler 是 Citrix 基础架构的核心部分，但它可能具有单独的更新周期、一组管理员等。这需要将 NetScaler 从其他 Citrix 组件分离为单独的资源组，以便 Azure RBAC 权限可以通过管理区应用租户、订阅和资源。

MCS 服务主体

要访问由 Azure AD 租户保护的资源，需要访问的实体必须由安全主体表示。这对于用户（用户主体）和应用程序（服务主体）都是如此。安全主体定义 Azure AD 租户中用户/应用程序的访问策略和权限。这将启用核心功能，例如在登录期间对用户/应用程序进行身份验证，以及在资源访问期间进行授权。

确定分配给 Citrix MCS 服务使用的服务主体的权限。

订阅范围服务委派人对 Citrix 环境使用的适用订阅具有参与者权限。窄范围服务主体已将精细的 RBAC 应用于包含网络、主映像和 VDA 的资源组。建议使用窄范围服务委派人将权限限制为服务所需的权限。这符合 “最低特权” 的安全概念。

标记

客户将标签应用于其 Azure 资源，从而提供元数据，以逻辑方式将它们组织到分类中。每个标签都由名称和值对组成。例如，他们可以将名称“环境”和值“生产”应用于生产中的所有资源。

客户可以使用该标签名称和值检索订阅中的所有资源。标签使他们能够从不同的资源组中检索相关资源。当管理员需要组织用于计费或管理的资源时，此方法非常有用。

每个资源限制为 15 个标签。Citrix MCS 为每台虚拟机创建 2 个标记，因此客户只能为 MCS 计算机创建 13 个标签。MCS 非持久性计算机在重新启动过程中被删除。这将删除 Azure 虚拟机特定的特征，例如标记、引导诊断如果需要标记，建议创建 Azure 追加策略并将其应用于适用的 MCS 资源组。

Azure 策略

Azure 策略可以控制标记、允许的 SKU、加密、Azure 区域和命名约定等方面。有默认策略可用，并且可以强制实施自定义策略。Azure 策略可以在订阅级别或资源组级别应用。可以定义多个策略。在资源组级别应用的策略优先于订阅级别策略。

确定应在 Citrix 环境中控制和标准化的 Azure 方面。硬配额强制执行政策，但不允许例外。软配额审计用于策略执行，如果不符合策略，则通知该策略。有关定义策略的详细信息，请参阅 Azure 文档。

Azure-RA-Image-6

示意图 6：Azure 治理访问策略和 RBAC

安全性

安全性已集成到 Azure 的各个方面。Azure 提供独特的安全优势，这些优势源自全球安全情报、面向客户的复杂控件以及安全的强化基础架构。这种强大的组合有助于保护应用程序和数据，支持合规性工作，并为各种规模的组织提供经济高效的安全性。

通过 CVAD 服务保护存储帐户资源调配

如前所述，MCS 是负责在客户订阅中启动计算机的服务（CVAD 内）。MCS 使用 AAD 身份 — 应用程序服务主体来访问 Azure 资源组，以执行不同的操作。 对于存储帐户类型的资源，MCS 需要在执行不同操作（写/读/删除）需要时获取密钥的listkeys权限。 根据我们目前的实施，对以下方面的 MCS 要求：

  • 存储帐户网络可以从公共互联网访问。
  • 存储帐户 RBAC 是listkeys权限

对于某些组织而言，保持存储帐户终端节点公开是一个问题。 以下是对使用托管磁盘部署 VM 时创建和存储的资产的分析（默认行为）。

  • 表存储： 我们将计算机配置和状态数据维护在主存储帐户中的表存储中（如果主存储帐户用于高级磁盘，则为辅助帐户）中的目录。 表中没有敏感信息。
  • 锁： 对于某些操作（将计算机分配给存储帐户、复制磁盘），我们使用锁定对象同步来自多个插件实例的操作。 这些文件是空 blob，不包含任何敏感数据。

对于 2020 年 10 月 15 日之前创建的计算机目录，MCS 会为身份磁盘创建额外的存储帐户：

  • 磁盘导入： 导入磁盘（身份、说明）时，我们将磁盘作为页面 blob 上载。 然后，我们从页面 blob 创建一个托管磁盘并删除页面 blob。暂时数据确实包括计算机对象名称和密码的敏感数据。这并不适用于 2020 年 10 月 15 日之后创建的所有计算机目录。

建议使用应用于特定资源组的窄范围服务主体，以将权限限制为服务所需的权限。这符合 “最低特权” 的安全概念。有关更多详细信息, 请参阅CTX219243和CTX224110。

IaaS-Azure 安全中心监视

Azure 安全中心分析 Azure 资源的安全状态。当安全中心识别潜在的安全漏洞时，它会创建建议，指导客户完成配置所需控制的过程。建议适用于 Azure 资源类型：虚拟机 (VM) 和计算机、应用程序、网络、SQL 以及身份和访问。您必须遵循以下几个最佳实践：

  • 控制 VM 访问和安全特权访问。
  • 配置反恶意软件以帮助识别和删除恶意软件。
  • 将反恶意软件解决方案与安全中心集成，以监视保护状态。
  • 使您的虚拟机保持最新状态，并确保在部署时构建的映像包含最新一轮的 Windows 和安全更新。
  • 定期重新部署虚拟机以强制使用新版本的操作系统。
  • 配置网络安全组和规则以控制虚拟机的流量。
  • 配置 Web 应用程序防火墙以帮助抵御针对 Web 应用程序的攻击。
  • 解决与建议基准不匹配的操作系统配置。

网络设计

网络安全可以定义为通过对网络流量应用控制来保护资源免遭未经授权的访问或攻击的过程。目标是确保只允许合法流量。Azure 包含一个强大的网络基础结构，可支持应用程序和服务连接要求。可以在 Azure 中的资源之间、本地资源和 Azure 托管资源之间以及与互联网和 Azure 之间建立网络连接。

虚拟网络 (VNet) 分段

Azure 虚拟网络类似于本地网络上的 LAN。Azure 虚拟网络背后的想法是，您创建一个基于私有 IP 地址空间的单一网络，客户可以在该网络上放置所有 Azure 虚拟机。最佳做法是将较大的地址空间分割为子网，并在子网之间创建网络访问控制。子网之间的路由会自动发生，您无需手动配置路由表。

使用网络安全组(NSG)。NSG 是简单的有状态数据包检测设备，它使用 5 元组（源 IP、源端口、目标 IP、目标端口和第 4 层协议）方法为网络流量创建允许/拒绝规则。规则允许或拒绝来自单个 IP 地址的流量、来自多个 IP 地址的流量或来自整个子网的流量。

客户可以在 Azure 中创建名为用户定义路由 (uDR) 的自定义或用户定义的路由，以覆盖 Azure 的默认系统路由，或向子网的路由表添加额外的路由。在 Azure 中，管理员可以创建路由表，然后将路由表关联到零个或多个虚拟网络子网。每个子网可以有零个或一个关联的路由表。

NSG和UDR应用于虚拟网络中的子网级别。在Azure中设计Citrix虚拟网络时,建议在设计虚拟网络时考虑到这一点，为类似组件创建子网，从而允许根据需要对 NSG 和 UDR 进行粒度应用。这方面的一个示例是将 Citrix 基础架构划分为自己的子网，每个使用案例都有相应的子网。

确定 Citrix 和支持技术所需的端口和协议。查看以验证环境中使用的网络安全组中是否允许使用这些端口。网络安全组可以将入站和出站通信限制为一组已定义的 IP、虚拟网络、服务标签或应用程序安全组。

Azure-RA-Image-7

示意图-7：使用 NSG 和 ASG 的 Azure 安全中心和网络安全

连接

将 Azure 虚拟网络与客户的本地/云网络连接称为混合联网。本节介绍了网络连接和网络服务路由的选项。 客户可以使用以下选项的任意组合将其本地计算机和网络连接到虚拟网络：

  • 点对点虚拟专用网络(VPN):在虚拟网络和客户网络中的单台计算机之间建立。每台想要与虚拟网络建立连接的计算机都必须配置其连接。此连接类型非常适合刚刚开始使用 Azure 或开发人员，因为它需要对客户的现有网络进行很少或根本不更改。您的计算机和虚拟网络之间的通信通过互联网通过加密的隧道发送。
  • 站点到站点 VPN：在本地 VPN 设备和部署在虚拟网络中的 Azure VPN 网关之间建立。此连接类型允许客户授权访问虚拟网络的任何本地资源。本地 VPN 设备与 Azure VPN 网 Gateway 之间的通信通过 Internet 通过加密隧道发送。
  • Azure ExpressRoute：通过 ExpressRoute 合作伙伴，在客户的网络和 Azure 之间建立。这个连接是私人的。流量不会通过互联网。

Azure 到客户连接的主要注意事项是带宽、延迟、安全性和成本。站点到站点 VPN 的带宽限制低于快速路由，并且取决于客户使用的边缘路由器的性能。服务级别协议在 VPN 网关 SKU 上可用。站点到站点 VPN 通过 Internet 使用 IPSEC。

Express Routes 是专用的专用连接，不是通过互联网进行的。这会导致使用快递路线时的延迟较低。此外，快速路线最高可扩展至 10 Gbps。快递路线是使用经过认证的合作伙伴配置的。在项目规划期间，应考虑这些提供商的配置时间。快递路线成本具有 Microsoft 组件和快递路线提供程序组件。

通常，这些连接在多个服务之间共享（数据库复制、域流量、应用程序流量等）在混合云部署中，可能会出现内部用户需要其 ICA 流量通过此连接才能访问 Azure 中的 Citrix 应用程序的情况，因此监视其带宽至关重要。

借助 ADC 和传统 StoreFront，还可以使用最佳网关路由，使用办公室的 ISP，而不是通过 Express Route 或 VPN 连接到 Azure。

用户定义的路由 (UDR)

通常，客户使用 UDR 将 Azure 流量路由到 Azure 中的防火墙设备或特定虚拟网络。例如，从 VDA 到互联网的北/南流量。如果将大量流量路由到 Azure 中的第三方防火墙设备，如果这些设备的大小或配置不当，则可能会造成资源瓶颈或可用性风险。NSG 可用于补充第三方防火墙，并应尽可能在适当的情况下加以利用。如果需要流量自省，请考虑 Azure 网络观察程序。

虚拟网络对等互连

虚拟网络对等互连无缝连接两个 Azure 虚拟网络。对等互连后，虚拟网络将显示为一个虚拟网络，用于连接目的。对等互连的虚拟网络中虚拟机之间的流量通过 Microsoft 主干基础架构进行路由，就像流量仅通过私有 IP 地址在同一虚拟网络中的虚拟机之间路由一样。

Azure 支持：

  • VNet 对等-连接同一 Azure 区域内的 VNet
  • 全局 VNet 对等-跨 Azure 区域连接 VNet

在多个 VNet 上部署工作负载的客户应考虑使用 VNet 对等来启用虚拟机之间的通信。

Azure-RA-Image-8

示意图 8：数据中心连接和路线

SD-WAN

软件定义的 WAN (SD-WAN) 技术可以提供出色的用户体验，即使在具有挑战性的连接中也是如此。它很适合虚拟应用程序和桌面交付。

  • 将所有可用带宽聚合到主动/主动连接中，从而提供更多带宽。
  • 使用独特的 HDX 体验质量技术来优化性能并调整网络策略。
  • 确保虚拟应用程序和桌面用户保持不间断连接，获得尽可能高质量的体验，即使是富媒体和高清视频也是如此。

使用 VPN 的客户可能会使用 SD-WAN 为 Azure 和客户数据中心连接添加冗余，或提供特定于应用程序的路由。Citrix SD-WAN 在任何可用连接上自动重定向流量。实际上，体验非常顺畅，用户甚至不会意识到发生了任何变化。他们的主要访问 IP 地址保持不变，允许用户使用相同的方法和设备访问其应用程序和数据。

Citrix ADC

Microsoft Azure 上的 Citrix ADC 可确保组织能够访问部署在云中的安全且经过优化的应用程序和资产，并提供建立网络基础以适应不断变化的环境需求的灵活性。如果数据中心出现故障，Citrix ADC 会自动将用户流量重定向到辅助站点，而不会中断用户。跨多个数据中心的负载平衡和全局服务器负载平衡进一步确保了最佳的服务器运行状况、容量和利用率。

与客户讨论并为每个资源位置定义以下使用案例：

访问方法 注意事项
仅限内部 如果只需要内部访问权限，则不需要 Citrix ADC。
通过 Citrix ADC 网关服务进行外部访问。 Citrix Cloud ADC 网关服务提供 ICA 代理（仅限安全远程连接）。
通过部署在 Azure 资源位置的 Citrix ADC VPX 进行外部访问 如果客户需要以下内容，则需要考虑在 Azure 中使用 Citrix ADC VPX 设备： 1. 具有完整的 SSON 2 的多重身份验证。端点扫描 3. 高级身份验证或预身份验证策略 4. Citrix SmartAccess 策略。注意：这些要求提示需要在 Citrix ADC 而不是在 Workspace 体验服务上进行身份验证。如果身份验证由 Citrix ADC 网关虚拟服务器管理，则需要 StoreFront。

Citrix ADC - 部署模型

主动-主动部署使用独立的 Citrix ADC 节点，这些节点可以使用 Azure 负载平衡器进行横向扩展。在节点发生故障时，主动-被动对促进 ICA 流量的状态故障转移，但它们仅限于单个 VPX 的容量。主动-被动节点还需要 Azure 负载平衡器。

建议使用多个 NIC 来隔离 SNIP、NSIP 和 VIP 流量，以最大程度地提高 Citrix ADC 网关或其他服务的可用吞吐量。

来源

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

引用

operations

身份

治理

安全性

Azure 监视器

连接

参考架构：Citrix DaaS - Azure
May 12, 2023
Author: Loay Shbeilat
Special thanks: Nitin Mehta
May 12, 2023
Author: Loay Shbeilat
Special thanks: Nitin Mehta

在本文中

站点反馈 | 隐私和法律条款 | Cookie 首选项 | 同意设置 | docs.cloud.com
© 1999-Cloud Software Group, Inc. All rights reserved.