Azure 虚拟桌面混合版用于本地 VDI

介绍

Azure Virtual Desktop Hybrid 为组织提供了在传统本地 VDI 和完全 Azure 托管的桌面之间的另一条路径。本文解释了架构的工作原理，Azure Arc 如何将本地会话主机连接到 AVD，现有 VDI 基础设施的变化，以及哪些限制仍然存在。它还探讨了何时使用 Hybrid AVD 是合理的，以及 IT 团队在采用之前应该评估哪些因素。

什么是 Azure 虚拟桌面混合？

Azure Virtual Desktop Hybrid是一种部署模型，其中Azure Virtual Desktop服务仍由Microsoft在Azure中托管和管理，但提供桌面和应用程序的Windows会话主机位于本地。

微软使用 Azure Arc 在环境之间建立连接。所有支持的本地计算机将成为 Azure Arc 启用的服务器。然后，Azure 虚拟桌面 Arc 扩展安装所需的 AVD 组件，并将该计算机注册为 AVD 主机池中的会话主机。

对于最终用户来说，一切或多或少都是一样的，就像他们使用托管在 Azure 中的 AVD 一样。用户通过 Windows 应用访问分配的桌面或应用程序。然而，区别在于 Windows 工作负载将从客户的基础设施交付，而不是从 Azure 计算交付。

因此，基础设施是分开的，其中：

组件	它运行的地方	谁来管理它
AVD 服务和经纪	Azure	微软
主机池、应用程序组和分配	Azure	客户配置它们
Windows 会话主机	本地	客户
虚拟机监控程序或物理基础设施	本地	客户
会话主机操作系统和应用程序	本地	客户
本地网络和存储	本地	客户
Azure Arc 集成	Azure + 本地	共享依赖

这里的主要观点是“混合”是对VDI架构中不同元素分布的描述。Azure虚拟桌面本身从未成为一个完全的本地解决方案。

Azure 虚拟桌面混合如何工作？

架构从提供桌面或应用程序的机器开始。组织在自己的基础设施上提供受支持的 Windows 虚拟机或受支持的无头物理设备。

Azure 连接机器代理将每个会话主机注册到 Azure Arc。然后，Azure 虚拟桌面 Arc 扩展可以安装所需的 AVD 组件并将机器注册到 AVD 主机池。

Azure Arc 不提供或管理基础虚拟机。会话主机是组织本地基础设施的一部分，这意味着组织的 IT 团队负责会话主机的生命周期、容量和基础虚拟化平台。

当用户连接时，Azure Virtual Desktop 提供服务端功能以发现资源、验证访问和调解会话。实际的 Windows 工作负载在本地会话主机上运行。

这种架构将AVD服务与会话主机分开，使混合AVD与两者区分开来。 传统本地VDI 和标准的 Azure 托管 AVD：微软管理云服务，但客户继续操作计算基础设施。

混合AVD如何改变现有的本地VDI环境？

对于现有的VDI环境，挑战不仅在于当前的服务器是否可以保留在数据中心，还在于现有架构的哪些层被保留，哪些AVD被替换，以及哪些运营责任由组织保留。

现有计算机可以保留在本地

与完整的 Azure AVD 迁移不同，在这种情况下，会话主机计算迁移到 Azure，这不需要对数据中心中现有的会话主机进行任何更改。

组织可以利用其首选虚拟化程序在本地数据中心上支持的 Windows 虚拟机。这在现有虚拟化基础设施较为庞大或应用程序严重依赖现有本地系统的情况下非常有用。

现有硬件的存在并不意味着VDI环境没有变化。然而，会话主机必须符合要求。 微软的规格 并在使用 Azure 虚拟混合桌面之前注册为 Azure Arc 启用。

VDI控制平面迁移到Azure

最显著的架构差异出现在会话主机上。

组织使用 Azure 虚拟桌面平台，而不是在内部操作完整的桌面交付堆栈。微软公开了服务的核心组件，以便进行资源发现、代理和网关连接。

组织仍然负责配置主机池、应用程序组、工作区和用户权限，但这些资源现在是AVD架构的一部分。之前的本地代理、网关和管理组件可能不再需要执行相同的功能。

本地基础设施管理保持不变

将服务层转移到 Azure 并不意味着支持基础设施由 Microsoft 管理。

IT团队仍然负责提供、修补和维护本地硬件、操作系统、应用程序、网络、存储和基础虚拟化平台。微软明确记录，Azure虚拟桌面混合版不提供本地会话主机虚拟机或管理其电源状态。

混合AVD应被理解为对VDI职责的重新分配，而不是将整个解决方案堆栈移交给微软。

在什么情况下将 AVD 会话主机保留在本地是有意义的？

如果Azure已经提供AVD服务，将该会话主机放入Azure可能看起来是最简单的路径。当有技术、成本或运营上的理由需要将工作负载保留在数据中心时，混合模式就会发挥作用。

遗留应用程序和本地依赖项

被虚拟化的应用程序通常是依赖于本地数据库、文件共享、身份验证服务、外设或其他后端系统的Windows应用程序。

将会话主机放在 Azure 中而将应用程序依赖项保留在本地并不会带来太多好处，因为这只会增加网络延迟。靠近后端可以避免为了改变最终用户的连接位置而拆除应用程序架构。

这尤其适用于 传统的业务应用程序 旨在本地网络环境中工作的。

数据位置和基础设施要求

一些公司需要某些工作负载或数据驻留在其控制下的基础设施上，以满足监管、合同或操作方面的要求。

混合AVD允许桌面和应用程序处理保持本地，同时使用Azure进行桌面交付服务。IT团队仍应仔细分析此架构选项与其合规要求之间的关系，因为混合模型仍依赖于Microsoft Azure。

现有数据中心投资

拥有可用服务器、存储和虚拟化资源的组织可能没有立即改变这一点的动力。

混合AVD可以让这些公司以波浪的方式获取新容量，在现有计算资源继续处理工作负载的同时，控制平面围绕它进行转型。该架构也适合迭代现代化，因为不同的工作负载可以以不同的速度迁移。

对后端延迟敏感的工作负载

对于某些应用程序，会话主机与其消耗的资源之间的接近程度比会话主机与最终用户之间的接近程度更为重要。

频繁调用本地数据库、存储系统或其他基础设施的应用程序，如果这些依赖项分布在广域网（WAN）上，可能无法正常运行。通过保持Windows会话本地，可以保持与这些资源的接近性。

当混合AVD可能不合适时

如果组织的目标是消除数据中心基础设施而不是维护它，那么保持会话主机在本地的价值就会降低。在这种情况下，使用 Azure 托管的 AVD 可能更符合所需的操作模型。

IT团队还应该考虑他们是否真的需要Azure虚拟桌面服务模型。如果主要需求是 集中式Windows应用程序或桌面的安全发布 在保留直接基础设施控制的同时，依赖于 Azure 的 VDI 控制平面可能会引入不必要的架构复杂性。

混合AVD是否消除VPN和RD网关？

Azure Virtual Desktop 通过允许组织避免将单个会话主机暴露于互联网或为 AVD 部署标准的远程桌面网关 (RD 网关)，消除了许多外部连接的复杂性。

AVD使用微软的服务基础设施通过微软服务进行连接。默认传输使用基于TCP的反向连接，而RDP Shortpath可以在网络和配置支持的情况下协商基于UDP的传输。

对于目前拥有VDI环境的组织，该环境使用入站远程桌面协议（RDP）连接以及其他方法，如VPN访问或本地管理的RD网关。 remote access 这可能会显著改变外部访问的架构。

网络连接要求并未消除。本地会话主机仍需连接到适当的 Azure 服务，而应用程序需要可靠访问本地依赖项。因此，DNS、身份、 firewall 配置、路由和弹性等连接考虑因素仍然是重要的设计元素。

Azure 虚拟桌面混合的限制是什么？

混合AVD提供了部署灵活性，但与Azure托管的AVD存在一些重要差异，这可能会影响架构和操作。

微软目前定义了几个 会话主机管理功能 作为对混合 AVD 不支持：

• 电源管理
• Azure 虚拟桌面自动缩放
• 连接时启动虚拟机
• 会话主机配置

企业将负责通过其虚拟机监控程序、脚本、自动化或其他工具提供这些功能。

此外，操作系统支持不同，因为不支持带有 Windows 10 企业版多会话和 Windows 11 企业版多会话的 Azure 虚拟桌面混合。这是一个显著的区别，因为多会话 Windows 客户端操作系统是 Azure 托管 AVD 的一个关键特性。

许可要求应仔细审查，考虑到预期的操作系统和使用案例。应确认微软的Azure虚拟桌面混合许可的要求是否适用于现有的VDI、远程桌面服务或Microsoft 365许可证之外。

最后，拥有本地会话主机并不使 AVD 部署与云独立，因为微软管理的 Azure 虚拟桌面服务仍然是架构的重要组成部分。

Azure托管的AVD与混合AVD与传统本地VDI

最终版本的句子（重写，使用不同的词汇，改变了一些句子的结构或长度）：

	传统本地VDI	Azure 虚拟桌面混合	Azure托管的AVD
会话主机	本地	本地	Azure
VDI 服务/控制平面	通常客户/供应商基础设施	Microsoft AVD 在 Azure	Microsoft AVD 在 Azure
本地虚拟机管理程序必需	通常是的	是的，针对基于虚拟机的主机	不
本地计算管理	客户	客户	不适用于本地计算
本地AVD虚拟机生命周期功能	不	有限	更广泛的支持
本地应用程序的接近性	高	高	取决于网络设计
Azure 依赖性	产品依赖	是	是
Azure 计算消耗	不	不适用于本地会话主机	是

因此，混合 AVD 具有中间架构，其中工作负载来自云（由 Microsoft 管理），但本地计算由客户管理。

只有在保持本地工作负载有益的情况下，这种架构选择才是合理的。

IT团队应该如何评估迁移到混合AVD？

混合AVD评估应从工作负载和依赖关系开始，而不是从Azure开始。

识别哪些应用程序和桌面必须保留在本地，并记录它们对数据库、文件服务、身份系统、外设、存储和其他基础设施的依赖关系。这使得能够确定在本地维护会话主机是否具有任何架构价值。

当前VDI堆栈的状态应映射到AVD模型。哪些代理、网关和管理服务将被Azure虚拟桌面替代？哪些操作责任将保留？

会话主机生命周期管理是一个关键考虑因素。如果现有的VDI平台包括自动配置、虚拟机的启动/停止或扩展，请评估这些功能是否在混合AVD中可用，而不是假设Azure控制平面会取代它们。

身份、网络、许可、弹性和运营责任应作为一个整体进行评估。目标不仅是确定现有机器是否可以与 Azure 虚拟桌面注册，还要确定在 Azure 和数据中心之间分离 VDI 基础设施是否会产生更简单和更可持续的环境。

寻找更简单的方法来交付Windows应用程序和桌面吗？

当一个组织特别希望使用 Azure 虚拟桌面，同时将会话主机保留在本地时，混合 AVD 是有意义的。但并不是每个组织都需要在 Azure 管理的服务和本地管理的计算之间拆分其桌面交付架构。

在主要要求是从现有的Windows基础设施安全地发布Windows应用程序或完整桌面时， TSplus 远程访问 提供更直接的替代方案。组织可以通过兼容RDP或基于浏览器的HTML5访问交付应用程序和桌面，同时保持对支持基础设施运行位置的控制。

结论

Azure Virtual Desktop Hybrid 提供了传统本地 VDI 和 Azure 托管 AVD 之间的折衷方案。它将关键的桌面交付服务迁移到 Azure，同时允许 Windows 会话主机及其工作负载保留在现有基础设施中。

决定性因素是保持这些工作负载在本地是否提供明确的技术或操作优势。IT团队应在决定混合AVD是否真正简化其VDI环境之前，评估应用程序依赖性、基础设施管理、网络、许可和Azure依赖性。