Azure 上的 Citrix Virtual Apps and Desktops 服务

简介

本指南帮助使用 Microsoft Azure 上的 Citrix Virtual Apps and Desktops 服务的体系结构和部署模型。

Citrix Cloud 和 Microsoft Azure 的组合使得能够以更高的敏捷性和弹性启动新的 Citrix 虚拟资源,并随着需求的变化调整使用情况。Azure 上的虚拟机支持 Citrix Virtual Apps and Desktops 服务部署所需的所有控制和工作负载组件。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 应用程序和桌面的三种最常见方案是:

  • 使用 Citrix Cloud 进行绿地部署,在 Azure 中提供资源位置。此方案是通过 Citrix Virtual Apps and Desktops 服务提供的,当客户更愿意使用订阅模式并将控制平面基础架构外包给 Citrix 时使用。
  • 将本地部署扩展到 Azure 中。在这种情况下,客户拥有当前的本地控制层,并希望将 Azure 添加为新部署或迁移的 Citrix 资源位置。
  • 升降和转移。在此方案中,客户可以使用 Citrix ADC 和 StoreFront 聚合来自多个站点的资源,将其 Citrix 管理基础架构部署到 Azure 中,并将 Azure 视为站点。

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

Citrix Virtual Apps and Desktops 服务

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

Citrix Virtual Desktops Essentials Service

Citrix 和 Microsoft 客户有更多的选项在组织内部署 Windows 10 企业版。Citrix Virtual Desktops Essentials Service 可加速面向偏爱 Microsoft Azure 云解决方案的客户的 Windows 10 Enterprise 迁移。这使每个用户拥有许可 Windows 10 企业级(当前业务分支)的客户可以选择从 Azure 提供高性能 Windows 10 企业级虚拟桌面体验。

Citrix Virtual Apps Essentials Service

新的应用程序虚拟化服务 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 Virtual Apps and Desktops 服务的可扩展性和经济性

操作

在操作主题区域,本指南深入了解基础服务的 Workspace 环境要求和层次结构的规划。在顶层,可以找到订阅、资源组和区域设计注意事项。随后是虚拟机存储、用户配置文件存储和主映像管理/置备的常见问题。还提供了有关使用自动扩展优化预留实例以及业务连续性/灾难恢复规划的指导。

命名约定

在 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 策略强制执行命名。

服务 范围 建议模式 示例
订阅 全局 [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 调用,从而降低了订阅中其他资源的可用性。

单一订阅 Workspace 模型

在单个订阅模式中,所有核心基础结构和 Citrix 基础结构位于同一订阅中。对于需要最多 1,200 个 Citrix VDA(可以是会话、池 VDI 或永久 VDI)的部署,建议使用这种配置。限制可能会更改,恕不另行通知,请查看以下内容了解大部分最新的 VDA 限制。有关单个订阅中最新的启动-关闭规模数字,请参阅以下博客

示意图 2:Azure 单一订阅 Workspace 模型 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 Virtual Apps and Desktops 需要在订阅中创建资源组和资源。例如,如果服务原则无法授予对订阅的完全访问权限,则需要授予该服务原则对预先创建的资源组的参与者访问权限。
开发和测试环境是否会在与生产单独的订阅中创建? 将开发和测试订阅与生产隔离,可以在隔离的环境和孤岛资源利用率中应用和更改全局 Azure 服务。此做法具有安全性、合规性和订阅性能的优势。为这些环境创建单独的订阅确实会增加映像管理的复杂性。应根据客户的需要考虑这些权衡。

Azure 区域

Azure 区域是在延迟定义的外围内部署的一组数据中心,并通过专用的区域低延迟网络进行连接。Azure 为客户提供了在需要的地方部署应用程序的灵活性。Azure 通常在全球 42 个区域可用,截至 2018 年 11 月,已宣布了另外 12 个区域的计划。

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

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

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

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

可用性集

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

Citrix 部署的每个组件都应位于其自己的可用性集中,以最大限度地提高 Citrix 的整体可用性。例如,应为 Cloud Connector 使用单独的可用性集,另一个用于 Citrix Application Delivery Controller (ADC)、StoreFront 等。

优化可用性集后,下一步是围绕可用性集中的虚拟机停机构构建恢复能力。这样可以最大限度地减少/消除 Microsoft 重新启动或重新部署 VM 时的服务停机时间。这也可以扩展到计划的维护事件。您可以使用两种功能,它们可以提高整体服务的可靠性。

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

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

Azure 计划维护

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

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

Azure 计划事件

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

这些事件以编程方式使用,并将提前通知如下:

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

灾难恢复 (DR)

Azure 可以为希望立即从云采用中获得价值的 Citrix 客户提供高性价比的灾难恢复解决方案。部署模型拓扑确定 DR 解决方案的实施。

扩展体系结构

在此拓扑下,管理基础结构保留在本地,但工作负载部署到 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) 是逻辑组中的资源集合,用于轻松甚至自动 Provisioning、监视和访问控制,并更有效地管理其成本。在 Azure 中使用 RG 的好处是将属于应用程序的相关资源分组在一起,因为它们共享从创建到使用的统一生命周期,最后是取消预配置。

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

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

映像管理

映像管理是创建、升级和分配映像的过程,该映像在开发、测试和生产环境中一致应用。开发映像管理过程时应考虑以下事项:

按需配置

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

存储帐户容器

客户需要决定使用 Citrix Machine Creation Services (MCS) 创建虚拟机的存储源(或金色)映像的组织结构。Citrix MCS 映像可以来自快照、托管或非托管磁盘,并可以驻留在标准存储或高级存储中。非托管磁盘可通过通用存储帐户访问,并以 VHD 形式存储在 Azure Blob 存储容器中。容器是可用于分隔生产、测试和开发映像的文件夹。

映像复制

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

文件服务器技术

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

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

客户应选择最符合其业务要求的文件服务器技术。下表概述了每种不同文件服务技术的一些优点和注意事项。

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

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

基础设施成本管理

有两种技术可用于降低 Azure 中 Citrix 环境的成本、预留实例和 Citrix 自动扩展。

预留实例

Azure 预留虚拟机实例 (RI) 在 Windows 和 Linux 虚拟机 (VM) 上以一年或三年的期限显著降低成本(与按需付费价格相比高达 72%)。当客户将 Azure RI 节省的成本与 Azure 混合权益的附加值结合起来时,他们可以节省高达 80% 的费用。80% 的计算基于 Windows 服务器的三年 Azure 预留实例承诺,与正常的即用即付费率相比。

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

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

Citrix Autoscale

AutoScale 是 Citrix Virtual Apps and Desktops 服务专有的功能,可提供一致、高性能的解决方案来主动管理计算机。它旨在平衡成本和用户体验。自动缩放将弃用的 Smart Scale 技术集成到 Studio 电源管理解决方案中。

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

Azure-RA-Image-4

图表 4:Citrix 自动缩放流

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

优化最终用户体验

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

定义用户 Workspace

在规划用户评估时,Citrix VDI 手册和最佳做法文档提供了宝贵的指导。查看以下高级别问题,以更好地了解现有用例及其最终用户所需的资源。

主题 问题
用户数 环境中预计有多少用户?评估阶段是否确定了适当的 VDI 模型?(Virtual Apps 或 Virtual Desktops)
用例 最终用户将使用哪些类型的应用程序?应用程序的 VDA 要求是什么?如何最好地交付应用程序?(Virtual Apps 与 Virtual Desktops)
用户组工作时间 用户何时访问环境?高峰时段是什么时间?全天的预期消费量是多少?(用户在特定时间内的消耗有助于确定扩展自动化和 Azure 预留实例购买的 Workspace 要求。)
位置 最终用户在哪里?应该跨多个区域部署工作空间,还是仅在单个区域部署工作空间?
用户和应用程序数据 用户和应用程序数据存储在哪里?数据是仅包含在 Azure 中,仅包含在本地,还是两者的混合?访问用户数据的最大可容忍延迟是多少?

Azure 虚拟机实例类型

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

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

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

客户基础架构中组件的大小和数量将始终取决于客户的要求、规模和工作负载。但是,使用 Azure,我们可以动态扩展和按需扩展!对于具有成本意识的客户来说,最好的方法是从小规模起步和扩大规模。Azure 虚拟机在更改大小时需要重新启动,因此仅在计划维护时段内并在已建立的更改控制策略下规划这些事件。

如何扩展或扩展?

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

如果每个用户每小时的成本需要最低,并且如果实例出现故障,则可以容忍更大的影响,则可以扩展最佳。当单个实例故障的影响需要最小化时,首选向外扩展。下表提供了不同 Citrix 组件的一些示例实例类型。

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

最新的实例类型研究是为了提供这方面的深入见解,我们强烈推荐使用阅读。在所有情况下,客户都应评估实例类型及其工作负载。

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

虽然向上扩展通常是降低成本的首选模型,但自动缩放可以从较小的实例中获益(每台主机 15-20 个会话)。较小的实例承载的用户会话少于较大的实例。因此,如果实例较小,AutoScale 将计算机置于耗尽状态的速度要快得多,因为注销最后一个用户会话所需的时间更短。因此,自动缩放更快地关闭较小的实例,从而降低成本。您可以在中阅读有关自动缩放实例大小注意事项的更多信息正式文件

存储

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

Azure 磁盘旨在提供企业级持久性。创建磁盘时可以选择三个存储性能层:高级 SSD 磁盘、标准 SSD 和标准硬盘存储,这些磁盘可以是托管的也可以是非托管的。托管磁盘是默认磁盘,不受存储帐户限制(如非托管磁盘)的约束。

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

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

身份

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

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

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

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

常见身份设计注意事项

通常,将客户 Active Directory 站点扩展到 Azure 使用活动目录复制来提供与 Citrix Workspace 的身份和身份验证。一个常见的步骤是使用 AD 连接将用户复制到 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 包括几个可以使用的内置角色。

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

Workspace Experience Service 尚不支持 Citrix FAS,因此 StoreFront 需要作为部署体系结构的一部分。 Azure MFA 服务器(云服务、Azure MFA 服务器、Azure MFA NPS 扩展)可以启用 Azure MFA 的使用,而不需要 SAML 策略和使用 Citrix FAS 进行完整 SSON。但是,这是 IaaS VM,必须由客户管理。

Active Directory 和 Azure Active Directory 结果

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

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

Azure-RA-Image-5

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

Citrix Cloud Administration + 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 身份验证的身份验证 URL 标识到 Citrix Cloud 中。URL 遵循格式https://citrix.cloud.com/go/{Customer Determined}

RBAC 权限和委派

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

在 Citrix 环境中,这些应以允许团队之间进行适当授权并促进最小特权概念的方式进行组织。一个很好的例子是,Citrix Cloud 部署使用从 Azure 市场预配置的 Citrix ADC VPX 进行外部访问。尽管 Citrix ADC 是 Citrix 基础架构的核心部分,但它可能具有单独的更新周期、一组管理员等。这需要将 Citrix ADC 从其他 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 日之后创建的所有计算机目录。

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

IaaS-Azure 安全中心监视

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

  • 控制虚拟机访问和安全特权访问.
  • 配置反恶意软件以帮助识别和删除恶意软件。
  • 将反恶意软件解决方案与安全中心集成,以监控保护状态。
  • 使您的虚拟机保持最新状态,并确保在部署时构建的映像包含最新一轮的 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 的带宽限制低于 Express Route,并且取决于客户使用的边缘路由器的性能。VPN 网关 SKU 上提供 SLA。站点到站点 VPN 通过互联网使用 IPsec。

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

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

使用 ADC 和传统的 StoreFront,最佳网关路由也可用于使用办公室的 ISP(而不是快速路由或 VPN 到 Azure)将用户与 ADC 的连接定向。

用户定义的路由 (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 体验质量技术优化性能并优化网络策略。
  • 确保 Virtual Apps and Desktops 用户始终保持连接,提供最高质量体验,即使对于富媒体和高清晰度视频也是如此。

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

Citrix ADC

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

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

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

Citrix ADC - 部署模型

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

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

来源

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

引用

操作

身份

治理

安全

Azure 监视器

连接