Azure 上的 Citrix Virtual Apps and Desktops

贡献者

作者: Loay Shbeilat

特别感谢:Nitin Mehta

简介

本指南帮助使用 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 管理基础结构部署到 Azure 中,并将 Azure 视为站点,使用 Citrix NetScaler 和 StoreFront 聚合来自多个站点的资源。

本文档重点介绍 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 服务的可扩展性和经济性有关的信息

operations

在操作主题区域,本指南深入了解基础服务的 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,000 个 Citrix VDA 的部署,建议使用此配置。

Azure-RA-Image-2

示意图 2:Azure 单一订阅 Workspace 模型

多订阅 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 的计划)主动对这些通知采取措施。

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

Azure 计划事件

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

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

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

灾难恢复 (DR)

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

扩展体系结构

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

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

托管体系结构

部署此拓扑时,Citrix 管理基础结构将部署到 Azure 中,并将其视为单独的站点。这在发生站点故障时提供了与本地部署的功能隔离。使用 Citrix NetScaler 和 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 的好处是将属于应用程序的相关资源分组在一起,因为它们共享从创建到使用的统一生命周期,最后是取消预配置。

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

在初始创建期间,可以将一个或多个资源组应用于计算机目录。这些资源组不能跨计算机目录共享。资源组限制为 240 个。由于资源组中每种资源类型的 800 资源计数限制,Citrix MCS 虚拟机。

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

映像管理

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

按需配置

客户需要确定是否使用 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-3x 磁盘空间。供应商可限制第三方备份软件支持。不支持多区域部署
分布式文件系统 — 复制 经过验证的基于文件的复制技术。支持 PowerShell 基于域的。无法在主动-主动配置中部署。
第三方存储应用程序 重复数据消除技术. 更好地利用存储空间。 额外费用。专利管理工具。

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

基础设施成本管理

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

预留实例

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

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

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

Citrix 自动扩展

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

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

自动缩放支持使用 Virtual Apps and Desktops、Virtual Apps and Desktops 服务、Virtual Apps Essentials 和 Virtual Desktops Essentials 功能管理站点。

支持使用这些服务之一的单个站点的电源管理,如下所示:

  • 每个站点最多可以管理 2,000 个 VDA 或 VDI。
  • 最多可以管理 120 个交付组。
  • 每个交付组最多可以管理 1,000 个 VDA 或 VDI。

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 的角度来看,大多数基础结构组件(Cloud Connector、StoreFront、NetScaler 等)都使用 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 一起运行良好。

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

对于图形密集型工作负载,请考虑由 NVIDIA 特斯拉 M60 GPU 和 NVIDIA GRID 技术与英特尔布罗德韦尔 CPU 提供支持的NV_v3-series虚拟机。这些虚拟机的目标是 GPU 加速图形应用程序和虚拟桌面,客户希望在这些桌面上可视化其数据、模拟结果以查看、处理 CAD 或渲染和流式处理内容。此外,这些虚拟机可以运行单一精度工作负载,例如编码和渲染。NV_v2 虚拟机支持高级存储,与其前身 NV-系列相比,具有两倍的系统内存 (RAM)。

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

存储

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

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

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

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

Microsoft Operations Management Suite (OMS)

OMS Workspace 最好由客户、工作负载类型、业务组或部门定义。例如,服务器 VDA、客户端 VDA、StoreFront 服务器都将拥有自己的 OMS Workspace。为了简化管理,请创建尽可能少的工作区。Microsoft 的运营管理套件中提供两种关键管理技术。

管理解决方案

管理解决方案通常会将信息收集到 Log Analytics 中,并提供日志搜索和视图来分析收集的数据。他们还可以使用 Azure 自动化等其他服务来执行与应用程序或服务相关的操作。

解决方案是一组服务、配置、事件 ID、容量等,可以针对给定工作负载捕获和监视。多个解决方案可应用于 OMS Workspace。确定哪些数据点对客户在 OMS Workspace 范围内的工作负载至关重要。解决方案是可供 OMS 使用的预构建或自定义模块,并分配给给定的工作区。

Workspace 日志分析

Log Analytics Workspace 是一个独特的日志分析环境,拥有自己的数据存储库、数据源和解决方案。目的是管理和访问来自 Azure 的日志数据,查找日志数据中的异常情况。

身份

本节重点介绍身份控制、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 访问格式为“https://citrix.cloud.com/go/{Customer Determined}”的 Citrix Cloud URL。
  • 将 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 VM 特定的特性,例如标签、引导诊断等。如果需要标签,建议创建 Azure 追加策略并将其应用于适用的 MCS 资源组。

Azure 策略

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

确定应在 Citrix 环境中控制和标准化的 Azure 方面。硬配额将强制执行政策,而不允许例外。软配额将审核策略执行情况,并在未满足策略时通知。有关定义策略的详细信息,请参阅 Azure 文档。

Azure-RA-Image-6

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

安全

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

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:通过快捷路由合作伙伴在客户的网络和 Azure 之间建立。这个连接是私人的。交通不会通过互联网。

Azure 到客户连接的主要注意事项是带宽、延迟、安全性和成本。站点到站点 VPN 的带宽限制低于 Express Route,并且取决于客户使用的边缘路由器的性能。VPN 网关 SKU 上提供 SLA。站点到站点 VPN 通过互联网使用 IPsec。

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

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

借助 NetScaler 和传统的 StoreFront,最佳 Gateway 路由也可用于使用办公室的 ISP(而不是快速路由或 VPN 到 Azure)将用户的连接引导到 NetScaler。

用户定义的路由 (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 而不是在工作空间体验服务上进行身份验证。如果身份验证由 Citrix ADC 网关虚拟服务器管理,则需要 StoreFront。

Citrix ADC - 部署模型

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

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

引用

operations

身份

治理

安全

Azure 监视器

连接

Azure 上的 Citrix Virtual Apps and Desktops