Citrix App Layering
读者
本文档面向技术专业人员、IT 决策者、合作伙伴和系统集成商。这将使管理员能够探索并采用 Citrix App Layering，以帮助管理向最终用户提供图像和应用程序。读者必须基本了解 Citrix 产品、映像管理服务和应用程序虚拟化概念。有关映像管理的详细信息，请参阅 Citrix 上的参考体系结构Tech Zone。
本文件的目标
本文档提供了使用 Citrix App Layering 技术管理和交付应用程序的技术概述和体系结构概念。本文档包括 App Layering 的工作原理以及与 Citrix Virtual Apps and Desktops 在不同平台上的集成。
Citrix App Layering 概述
Citrix App Layering 是一种灵活的解决方案，可为任何非持久性支持的平台上的不同用户提供一组复杂的 Windows 应用程序。
Citrix App Layering 以独特的方式执行图像管理。操作系统和应用程序被拆分为不同的容器，称为 “Layers”。层将独立创建和更新，然后将其编译成 “已发布映像”，以便使用任何受支持的配置系统进行分发。
创建应用程序库后，将使用任意图层组合将不同的映像集部署到多个平台。
Citrix应用程序分层的主要目标是使用单一界面简化窗口应用程序管理。它允许管理员创建和管理企业应用程序，而不考虑底层虚拟机管理程序或云基础结构。
操作系统和应用程序分为独立的可管理单元。即使需要多个映像才能正确控制应用程序访问，每个操作系统及其应用程序都会作为一个实例进行管理。在这种方法中，不必对环境中的每个映像执行更新。简化环境，同时减少与操作系统和应用程序管理相关的管理时间、复杂性和成本。
操作系统和应用程序存储为虚拟磁盘，其中包含特定层的文件和注册表项。在虚拟机中包含应用程序的方法有两种：
- 已发布映像：此方法结合操作系统层、平台层和一组应用程序层,以创建用于置备系统(如Citrix条款ning 或 Citrix Machine Creation Services）的映像。App Layering 可以将映像发布到多个 Provisioning 系统和来自同一组层的多个虚拟机管理程序。
了解有关 Citrix 映像管理的详细信息，请参阅参考体系结构文档。
- 弹性层：根据 AD 组成员身份和应用程序分配，登录期间将很少应用程序层连接到虚拟机。允许将应用程序动态交付到标准化图像，从而提高应用程序分配的灵活性。
将应用程序和个性化与操作系统分离，为非持久性映像管理提供了灵活且易于管理的解决方案。
为什么 Citrix App Layering
Citrix App Layering 提供了一种具有成本效益的解决方案，用于跨多个环境管理具有不同打包要求的复杂应用程序集。几乎所有嵌入内核驱动程序、操作系统和系统服务依赖关系的应用程序都与 App Layering 技术兼容。
采 Citrix App Layering 方法进行图像管理有许多优点：
简化 PVS 和 MCS 的主映像管理：Citrix App Layering 是一种单一映像管理解决方案，支持 Citrix 和第三方虚拟机管理程序一起使用的 Provisioning 模型。使用 App Layering 管理和图像升级都可以简化，无需直接编辑或反向映像。
Azure 支持：Citrix App Layering 支持 Microsoft Azure，并使 App Layering 客户可以轻松迁移到 Azure 平台。
将应用程序和预配系统与映像分离：Citrix App Layering 将打包与映像分离开来。在正常的映像管理中，对映像分别执行每个映像的更新。使用 App Layering 图层可以是许多图像的一部分。要更新所有图像，图层将被更新一次，并重新生成图像。升级到虚拟机管理程序工具、Virtual Delivery Agent (VDA) 和 Citrix Provisioning 工具等组件变得轻松。
支持复杂的使用案例：使用Citrix应用程序分层可以支持具有内核驱动程序,系统服务,第三方驱动程序和控制台访问的复杂应用程序。由于，App Layering 的两种应用层部署模式几乎所有应用程序都兼容。
非持久性桌面用户层：用户层是可写的弹性层。用户登录到桌面大多数写入操作都会进入用户层。它允许用户安装应用程序并保存用户配置文件外部的配置设置。此外，它通过使他们的桌面似乎是持久性的，具有共享桌面模型的好处来存储用户的数据文件。
减少所需映像的数量：弹性分层可以通过在登录时将应用程序动态交付给分配的用户，显著减少所需映像的数量。弹性图层与 Citrix Virtual Apps 和 Citrix Virtual Desktops 兼容。
Citrix App Layering 使用案例
App Layering 是 Citrix 技术产品组合的一个重要补充，它提供了上面列出的许多优势。虽然它提供了好处，但 App Layering 并不意味着将它用于所有的用例。本节概述了几个最相关的用例，以展示 App Layering 技术的优势。
1 张图片太多无法管理
许多 Citrix 客户必须支持大量的应用程序和一组复杂的用户要求。使用基于映像的 Provisioning 技术时，满足这些要求通常需要管理大量映像。这些映像必须支持不同的用户组或不同的冲突应用程序集。部署到每个映像的应用程序通常也有一些重叠。
Citrix App Layering 简化了这种复杂方案的管理。
App Layering 允许管理员将操作系统和应用程序作为使用层的单个实体进行管理。例如，需要修补 Windows，修补程序会对操作系统层进行一次修补，并且使用 App Layering 设备更新的操作系统层的所有映像。如果在 10 个映像中使用 Microsoft Office，升级此办公室是更简单的，通过将版本添加到 Office 层。最终，所有这 10 张图像都会自动更新。
添加弹性分层时，也可以显著减少所需图像的数量。弹性层允许管理员在登录期间动态交付应用程序。对于不是每个人都使用的应用程序，弹性图层允许更通用地创建图像，同时为每个用户提供自定义。
2-支持多个虚拟机管理程序和 Azure
许多组织正在迁移到混合本地资源和云资源的多云混合环境，以增强用户体验。Citrix App Layering 通过为每个所需环境创建不同的平台层来支持大多数虚拟机管理程序和 Microsoft Azure，从而提供映像可移植性。
通常，混合管理 Hypervisor 和混合云配置会迫使管理员在多个不同的管理平台中维护多组不同的映像和应用程序。借助 App Layering 技术，可将本地使用的相同操作系统和应用程序推送到云或另一个 Hypervisor，无需额外工作即可。
要了解，关于 App Layering 跨平台功能，请参阅下面的Citrix App Layering 跨平台支持部分。
3- 适用于迁移的虚拟机管理程序可移植性
企业通常会 “困扰” 供应商的技术，仅仅是因为迁移到新技术的成本太高。此外，公司经常与作出不同技术选择的其他组织合并。App Layering 的一个明显优势是可以通过创建不同的平台层，并通过导入导出将 App Layering 设备迁移到新平台，从一个平台移动到另一个平台。
允许无缝迁移，例如，从 vSphere 到 Citrix Hypervisor 或从本地虚拟机管理程序迁移到 Azure。
共享 VDI 桌面的 4 持久性
许多组织都有多个用户需要高级别的桌面持久性。包括任何组中的高级用户、开发人员、工程师、体系结构师等。App Layering 用户层在池桌面体系结构之上提供了大量持久性。
登录时挂载用户层，桌面上的任何后续写入都会写入到用户层。大多数应用程序都可以安装在用户层中。用户层中有效的规则与弹性分层相同。只要应用程序不安装内核驱动程序、第三方驱动程序以及在引导过程中依赖于其他服务的服务，它们最有可能在用户层中工作。
对于需要持久性的用例，用户层是最佳选择。对于仅支持 Microsoft Outlook OST 文件和索引文件的使用案例，用户层可能不是最佳选择。用户层旨在处理用户登录后对 VDI 桌面的所有写入操作。其他技术，例如 Citrix 配置文件管理 Outlook 容器或 Fslogix 配置文件或 Office 365 容器以更有针对性的方式处理 Outlook OST 和索引，因此容器处理的 I/O 量将大大减少。所有这些解决方案现在都可以处理 Outlook OST、Outlook 流文件和 Outlook 索引文件的管理，因此支持索引不再是选择一种技术而不是另一种技术的理由。
Citrix App Layering 的技术概述
图层类型
层是包含在打包过程中更改或添加的文件和注册表项的虚拟磁盘。除了第一个版本的操作系统层外，层是由与虚拟机管理程序集成的 App Layering 设备创建的。管理员创建一个图层时，设备会动态置备包含一个引导盘和一个图层磁盘的打包计算机。当包装机启动时，包装机器上的所有更改都写入层磁盘。打包完成后，将此磁盘复制回设备，并将所有文件和注册表更改写入新图层并以 VHD 格式存储在图层存储库中。
App Layering 使用以下不同类型的图层：
- 操作系统层
- 平台图层
- 应用程序层
- 完整用户图层
操作系统层：操作系统，如 Windows 10 或 Windows Server 2019。从虚拟机管理程序中的 “黄金映像” 虚拟机构建。
平台层：平台层包括支持特定平台所需的软件。如果管理程序与默认管理 Hypervisor 不同，则包括代理代理、Provisioning 系统和管理程序工具。平台层也是最高优先级层，有时在这里安装软件，以便按最高优先级编译。
应用程序层：主图层类型。用于大多数应用软件。
用户图层：弹性图层（请参阅下一节）可写图层。用户层在登录时装入，一旦装入，几乎所有的桌面写入都会转到用户层。该层使用户能够显著自定义其 VDI 体验，即使他们使用共享桌面模型。
Citrix App Layering 设备
Citrix App Layering 设备（设备）既提供 App Layering 的管理界面，也提供所有 App Layering 进程的引擎。
App Layering 设备作为虚拟机部署到应用程序打包和映像发布的数据中心。App Layering 设备基于 CentOS 构建，配置了 4 个 vCPU 和 8 GB 的 RAM。这些设置不会更改，因为设备设计为在该配置中工作。
该设备由两个磁盘构建。第一个磁盘是用于操作系统的 30 GB 引导磁盘。第二个磁盘是 300 GB 图层存储库。如果需要更多空间，可以根据需要扩展或扩展此磁盘。
在创建图层和映像发布过程中，Citrix App Layering 设备将 VHD 格式的虚拟磁盘文件保存到设备内的图层存储库。设备与 SMB 共享接口，以支持设备升级过程和存储弹性层。
设备仅用于管理图层、图像和弹性图层分配。Virtual Desktops 和虚拟应用程序服务器不直接与设备接口。以弹性方式分配图层时，设备会将该图层复制到弹性图层共享。该共享保存这些 VHD 文件以及一组 JSON 文件，这些文件为用户提供图层分配。
Citrix App Layering 设备还托管 App Layering 管理控制台。部署 App Layering 设备是安装过程中的第一步。安装设备后，将访问管理控制台以完成安装步骤。
了解有关安装 Citrix App Layering 设备的详细信息，请参阅产品文档。
Citrix App Layering 管理控制台是托管在 App Layering 设备上的基于 Web 的应用程序。App Layering 管理控制台提供了以下界面：
- 创建和管理操作系统、平台和应用程序层
- 创建已发布的映像模板
- 发布和管理分层图像
- 将 App Layering 管理员角色分配给用户
- 管理设备和系统设置，如任务和日志保留、安全设置和网络文件共享
合成引擎
1910 及更高版本的新功能是一项名为合成引擎的功能。合成引擎可以卸载大部分打包和发布任务，这些任务也可以由 App Layering 设备执行。通过卸载这些任务，打包和发布流程可以更好地扩展，并且由于所用技术的优势，流程的性能也得到了显著提高。
合成引擎是由 Hypervisor 连接器构建的，作为 Windows PE 虚拟机，该虚拟机执行一组发布任务，然后将自身重新启动到打包机或已发布映像中。合成引擎用于创建缓存的图层磁盘、创建打包机和发布图像。在撰写此参考体系结构时，分别在 1910 和 1911 版中引入了适用于 HyperV 和 vSphere 的合成引擎。
合成引擎具有以下特征：
- 运行 Windows PE 的轻量级、短暂的设备
- 自我合成
- 通过 REST API 控制
- 支持的虚拟机管理程序磁盘格式（VHD、VHDX 和 VMDK）
- UEFI 支持（Gen2）
- 对已发布映像进行安全启动（仅当未使用弹性分层或用户层时）
- iSCSI 用于附加应用程序分层设备上托管的磁盘
- 同时发布作业的数量没有限制（实际上有限制）
合成引擎的优势
使用合成引擎是一种选择。在 HyperV 连接器和 vSphere 连接器中，有一个复选框用于启用 “卸载合成”。此设置在 vSphere 的计算机创建和 VMware Horizon View 连接器中也可用。合成引擎的显著优势是它运行在可直接访问虚拟机管理程序磁盘的 Windows 设备上。5723 这提供了支持 HyperV、本机 ESX VMDK 格式的 GEN2 计算机的机制，并在 vSphere 和 UEFI 中使用精简资源调配。打包和发布性能得到了增强，因为合成引擎处理较少，然后由合成引擎连接回应用程序分层设备以使用 iSCSI 连接访问层，直接写入虚拟机管理程序上的磁盘。
注意：PVS 发布尚不能使用合成引擎执行，因此仍然无法将 VHDX 文件或 GEN2 虚拟机直接发布到 PVS。
图层交付
图层可以通过两种方式进行交付。作为已发布映像的一部分，App Layering 设备将所有图层合并到单个磁盘文件中，然后将该文件上传到 Provisioning 备系统，或者在登录时装载图层并动态供用户使用。
已发布映像：此处，操作系统、平台和一组应用程序层将合并为单个磁盘文件，该磁盘文件将发布到配置系统（如 Citrix Provisioning 或 Machine Creation Services）。该过程从克隆操作系统层开始，然后按优先顺序一次写入应用程序层中的文件，其中层越新的优先级越高，最后写入平台层。创建已发布映像的合并过程已高级。创建映像后，文件系统、注册表和环境变量将合并 Windows 驱动程序存储区将重新创建合并来自不同层的所有第三方驱动程序。
弹性图层：这些图层是由 Active Directory 组成员身份分配给用户的应用程序图层，并在登录期间或登录后稍微附加。弹性图层是动态的，允许管理员自定义用户体验，同时最大限度地减少图像数量。
连接器和连接器配置
App Layering 设备使用连接器与虚拟机管理程序和 Provisioning 系统集成。
有两种类型的连接器-Hypervisor 和 Provisioning：
Hypervisor 连接器提供了与虚拟机管理程序进行接口的机制。目前，有 Citrix Hypervisor、vSphere、Hyper-V、Nutanix AHV、Azure 和 Azure 政府的虚拟机管理程序连接器。
Provisioning 系统连接器允许管理员将映像发布到置备系统。目前，在每个虚拟机管理程序和 Horizon View 上都有适用于 Citrix Citrix Provisioning 的预配系统连接器、Citrix 计算机创建
通过定义更多连接器，单个设备可以连接到任意数量的虚拟机管理程序或 Provisioning 备系统。连接器配置定义与 Hypervisor 或置 Provisioning 系统集成所需的设置。配置通常包括身份验证凭据、存储位置、VM 模板以及与管理员创建图层或发布映像的环境进行接口所需的任何其他信息。管理员可以创建多个连接器配置，每个配置都配置为访问环境中的唯一位置。连接器用于：
- 创建操作系统图层时导入金色图像
- 创建图层和图层版本
- 将分层映像发布到 Hypervisor 或置备服务。连接器配置还可以包括在 Provisioning Server 上运行的 PowerShell 脚本，也可以包括具有主机代理的系统上运行的 PowerShell 脚本，以便对已发布映像执行后处理
参考资料：连接器配置
连接器类型
本部分定义 Citrix App Layering 中可用的连接器类型。
虚拟机管理程序连接器
创建图层或导入金映像以创建操作系统图层时使用虚拟机管理程序连接器。打包时，虚拟机管理程序连接器在由连接器配置定义的存储和主机上动态创建打包计算机。Hypervisor 连接也可用于在 Hypervisor 中创建虚拟机。
Citrix Provisioning
Citrix Provisioning 连接器与 Citrix Provisioning 服务器上的 App Layering 代理集成，以便将映像作为虚拟磁盘直接发布到配置服务器。Citrix Provisioning 的先决条件是：
- 连接器服务帐户必须是具有 PVS 中管理员权限的域帐户。
- 连接器服务帐户还必须是 Citrix Provisioning 服务器上的本地管理员。
- 必须在连接器中定义的每个 Citrix Provisioning 服务器上安装 Citrix App Layering 代理。每个连接器只能定义一个代理。
参考资料：Citrix Provisioning
Machine Creation Services
Citrix App Layering 设备可以将分层映像作为虚拟机直接置备并将其发布到虚拟机管理程序，该虚拟机用作 MCS 的主映像。连接器允许分层映像直接发布到 Hypervisor。MCS 连接器与虚拟机管理程序连接器几乎相同，只是 MCS 连接器启动已发布的虚拟机，该虚拟机允许在层中定义的任何脚本在 MCS 部署之前在主映像上运行。作为此过程的一部分，主映像关闭和虚拟机快照。
连接器脚本
此步骤是创建连接器配置时可用的可选高级功能。要使用此功能，请将可选的 PowerShell 脚本配置为在连接器配置上定义的代理服务器上运行。此步骤通常与 Citrix Provisioning 配合使用，但通过在 Windows 系统上安装 App Layering 代理以针对已发布映像运行脚本，可与任何其他发布连接器一起使用。将脚本复制到安装代理的计算机上。此脚本在成功部署分层映像后运行。要使用此功能，对于 Hypervisor 上的主映像，脚本还必须与 Hypervisor 的管理平台进行接口。例如，对于 vSphere，脚本需要针对 vCenter 使用 PowerCLI 来针对主映像虚拟机运行代码。
通过某些预设变量，可以使用不同的模板映像和不同的连接器配置来重复使用脚本。变量还包含将虚拟机识别为已发布映像的一部分的信息。
了解有关示例脚本的详细信息，请参阅以下支持文章CTX226060和CTX226062。
已发布的图像模板
使用 App Layering 时，App Layering 设备将合并操作系统、平台和应用程序层以创建已发布的映像。映像将发布，然后以目标 Provisioning 系统所需的格式创建。例如，如果管理员发布到 Citrix Provisioning，则设备会创建 VHD 并将其作为虚拟磁盘上传到定义的配置服务器。如果解决方案在 Citrix Hypervisor 拟机管理程序上使用 Machine Creation Services，则设备将创建 VHD，将其上传到 Citrix Hypervisor 并使用 VHD 创建主映像 VM。
要定义已发布映像的配置，请使用图像模板。映像模板定义映像中包含哪些操作系统、平台和应用程序层。它还定义了用于发布图像的连接器、生成图像的 GB 大小、图像是否启用了弹性分层还是其中一种不同类型的用户图层。映像模板是映像配置的时间点快照，不支持版本控制。但是，如果需要稍有不同版本的同一映像，则可以克隆和修改图像模板。
App Layering 代理
Citrix App Layering 代理提供 App Layering 设备与 Citrix Provisioning 服务器、Hyper-V 服务器或仅用作脚本服务器的 Windows 计算机之间的通信。在将映像发布到其他虚拟机管理程序（如 Citrix Hypervisor 或 vSphere）后，还可以使用 App Layering 代理自动执行脚本。 对于 Citrix Provisioning 和 Hyper-V，App Layering 连接器将联系 App Layering 代理，并要求其将设备已编译的 VHD 传输到代理的服务器。此传输使用 BITS 从代理启动，并从设备下载文件。
Citrix App Layering 代理详细信息可在 Citrix 文档中找到。
参考资料：安装代理
Active Directory
App Layering 设备连接到 Active Directory，以便对设备进行身份验证和分配弹性层。当管理员登录设备时，它会尝试使用相同凭据登录到 Active Directory。如果该登录有效，则允许用户进入设备。
出于以下目的，需要访问目录服务：
- 基于角色的访问控制 (RBAC)
- 弹性和用户层的分配
在与目录服务的初始绑定期间，App Layering 设备与 SSL 3.0 安全套接字层以及 TLS 1.1 和 1.2 传输层安全性兼容。
要创建目录交汇点，请参阅产品文档。
层
以下部分更详细地介绍了每种类型的图层的用途。
操作系统层
操作系统层是包含 Windows 操作系统的层。这是一个领先的做法，在操作系统层中包含将使用 Windows 更新进行更新的任何组件，以便所有组件都由 Windows 更新进行更新。因此，所有操作系统角色和组件（如 .NET 和 Visual C++ 运行时库）都包含在操作系统映像中。
最好不要将最终用户应用程序安装到操作系统层，因为使用特定操作系统层创建的所有应用程序层都与该操作系统层相关联。如果某个应用程序安装在操作系统层中，那么每个使用该层的图像将该应用程序包含在此过程中，当策略是使操作系统层通用时都会出现问题。将应用程序与操作系统分离是限制要管理的操作系统映像数量的关键。甚至包含驱动程序、服务和内核设备的应用程序在应用程序层中也受支持，不需要包含在操作系统层中。
在此期间，操作系统层的创建有几点要记住：
- 从链接检查支持的操作系统
- 操作系统层未连接到域。域加入是平台层的一部分
- 主 Hypervisor 的管 Hypervisor 工具安装在操作系统层中。执行大多数打包的 Hypervisor
- 备用 Hypervisor 的 Hypervisor 工具已安装到该虚拟机管理程序的平台层中
- 在操作系统层中安装 .NET 组件（来自 Microsoft）和更新
- 如果需要 Microsoft 运行时，它们将安装在操作系统层
- Windows 角色和功能（如安装在操作系统层中的 RDS 角色），以便可以使用 Windows 更新更新
- 如果需要将本地用户或组添加到虚拟机，则此任务只能在操作系统层中完成，因为 Windows 安全帐户管理器 (SAM) 从操作系统层捕获
参考资料：创建操作系统层
平台层
平台层是一个包含在特定平台上运行已发布映像所需的配置设置、工具和其他软件的层。可以创建两种平台图层类型：
发布平台层：此类型的平台层用于包含目标 Provisioning 系统、代理和 Hypervisor 所需的软件。例如，用于支持 Citrix Virtual Apps 程序 vSphere 上的 Provisioning Services 的发布平台层已安装 Citrix VDA 和 PVS 设备驱动程序。如果 vSphere 与执行打包的 Hypervisor 不同，则此层还安装了 VMware Tools。
包装平台层：如果需要包装层来支持包装机器，则使用包装平台层。这些图层通常不是必需的，但有几种情况下必须有一个必要的，包括：
如果图层必须打包在不同于标准的 Hypervisor 上。例如，如果大多数图层是在 Hyper-V 上创建的，但由于某种原因，在 vSphere 中创建的特定图层，则使用带 VMware Tools 的打包平台图层来支持 vSphere 上的打包计算机。
如果需要使用 VDA 软件访问打包机。当安装 USB 外围设备的驱动程序时，最常需要此层，这些驱动程序必须看到设备才能正确安装。通过在安装了 VDA 软件的情况下创建打包平台图层并将打包计算机添加到 Studio 中手动置备的目录，可以支持此类访问。
创建平台图层
为了创建平台层，需要记住几点：
- 对于 Citrix Provisioning，安装目标设备软件时不运行映像向导，然后重新启动
- Citrix VDA 和 Citrix Provisioning 设备驱动程序的安装进入平台层
- 域加入在平台层中执行，这意味着可以创建多个平台层来支持不同的域
- 平台层也是最高优先级层，因此可以安装一些可选组件，包括诸如 Imprivata 之类的 SSO 软件、备用虚拟机管理程序的管理程序工具以及 Citrix Workspace Environment Management Agent。
了解有关平台图层创建的详细信息，请参阅文章CTX225997。
应用程序层
应用程序层用于打包大多数应用程序。应用程序层包含应用程序或应用程序组的文件系统和注册表对象。创建或编辑图层时，会动态创建打包机，并在该计算机上捕获所有文件系统和注册表更改。打包机包含操作系统层和任何包含的先决条件应用层。另一个名为“包磁盘”的虚拟磁盘作为可写卷附加到打包机。该磁盘捕获打包过程中的所有文件系统更改，并且还包含用于捕获所有注册表更改的注册表配置单元（称为 RSD 配置单元）。打包机完成后，只下载软件包磁盘。启动磁盘已被删除。
了解有关创建和编辑应用程序层的详细信息，请参阅产品文档。
大多数情况下，应用程序的安装配置与管理员通常用于支持的 Provisioning 系统的配置相同。在创建应用程序层时，始终需要解决禁用自动更新问题。因为管理员通常不希望应用程序在部署后自动更新。Citrix 已经记录了一些常见应用程序的分层过程. 这些应用程序分层 “食谱” 可以在以下链接中找到。
参考资料：App Layering 窍门
弹性分层
弹性分层是一种用于在用户登录期间将应用程序动态部署到虚拟会话的方法，方法是在 SMB 共享上装载作为 VHD 文件存储的图层，并使用 Citrix 复合文件系统 (CFS) 将它们集成到文件系统中。弹性分层由 Citrix 分层服务在 VDA 上管理。弹性层存储库是一个 SMB 共享，其中包含图层 VHD 文件和 JSON 配置文件，这些文件用于定义分层服务的图层分配。分层服务读取配置文件，然后使用 WindowsSDK 调用挂载层 VHD 文件。
弹性分层技术不支持所有应用程序，因为弹性层在登录期间安装。以下应用程序要求将应用程序排除在弹性图层中使用：
- 具有内核驱动程序的应用程序
- 具有与其他引导时服务相关的服务的应用程序
- 修改 Windows 驱动程序存储的应用程序，如第三方打印机驱动程序
具有这些要求的应用程序可以分层，但必须将图层包含在已发布的映像中。
配置文件 (JSON)
如上所述，弹性层分配是在弹性层存储库中存储的一组 .JSON 文件中定义的。这些文件的定义如下：
ElasticLayerAssignment：此文件包含有关用户和组映射到应用程序层的信息。此文件包含已分配应用程序的每个组或用户 ID 的条目，并在该 AD 对象的 SID 下列出了图层分配。
Layers.json：此文件定义了存储库中的图层以及有关该图层的元数据。此文件用于获取用于装载 VHD 的路径。
MachineAssociations.json：如名称所示，它定义了与任何 AD 组的计算机关联，该格式使用包含通配符的计算机名模式将一组计算机与定义的 AD 组关联。当用户登录到与该模式匹配的计算机时，他们会收到分配给该组的弹性层。这些设置在用户 > 组部分的“App Layering 管理控制台”中定义。
用户层
用户层为用户提供更持久的体验，同时仍然支持共享桌面计算模型。之后，装入用户层大多数系统写入都会重定向到用户层。此图层允许支持以下内容：
- 每个用户的配置文件和数据设置都存储在用户层
- 用户层支持用户安装的应用程序，只要这些应用程序符合弹性层允许的规则
将为用户层分配一对一。每个域的每个操作系统层只能有一个用户可写图层。因此，用户只能使用同一操作系统层和平台层组合并启用了用户层的桌面登录到一个交付组或池。当用户首次登录时，此图层将作为文件共享上的虚拟磁盘创建。
自 1910 版本起，完整用户层支持会话之间的搜索索引持久性。为了支持此功能，Windows 搜索服务在启动时将 VDA 上的 Windows 搜索服务设置为已禁用 (4)。当用户登录 Ulayer 服务时，Windows 搜索服务的启动类型更改为 START_ON_DEMAND (3)。在启用 wSearch 之前，Ulayer 服务还必须确保索引器的 “抓取范围” 注册表设置正确无误。Crawl-scope 是一组注册表项，用于确定要索引的用户数据的区域。Crawl-scope 的输入来自基础映像中内置的默认值，但也可以来自弹性层和用户的持久性层设置。这些输入在登录时进行处理，以提供完整的抓取范围位置，为每次登录构建这些输入都会带来不大但可衡量的开销。为了避免这种开销，Ulayer 服务会生成一个哈希字符串来表示基础映像部署（例如 BIC 实例）和弹性层分配，并将此字符串存储在用户的\ Program Files\ Unidesk\ EcTes\ userLayer.JSON 文件中，作为 “IndexerHash”。在后续登录时，将此字符串与重新计算的 IndexerHash 进行比较，只有在它们不同时，才重新构建抓取范围。
可以使用以下类型的用户图层：
- 完整：用户的所有数据、设置和本地安装的应用程序都存储在其用户层
- Office 365：只有用户的 Outlook 数据和设置存储在用户层中。每次登录都会重新创建搜索索引。
- 会话 Office 365：只有用户的 Outlook 数据和设置存储在用户层中。每次登录都会重新创建搜索索引。
注意：如果使用 Office 365 层，建议使用 Citrix 配置文件管理来保留 Outlook 设置。
用户图层的默认最大大小为 10 GB。可以通过为用户图层共享定义配额来更改此大小。还可以使用 VDA 上的注册表项覆盖默认的用户层最大大小。若要更改默认的最大大小，请添加以下注册表覆盖，
HKLM\Software\Unidesk\ULayer\
DWORD: DefaultUserLayerSizeInGb
VALUE:
弹性层共享和用户层共享
弹性层是由客户端或服务器操作系统通过虚拟机网络挂载的 VHD 文件。弹性图层以只读方式装载，许多计算机可以装载完全相同的 VHD 文件。用于弹性图层的文件服务器或共享针对读取 I/O 进行了优化。
用户层是可写的弹性层。只有一个桌面安装用户层读/写。用于用户层的文件服务器或共享是针对写入 I/O 进行优化的，当使用用户层的存储性能对用户体验至关重要。强烈建议用户层共享使用闪存存储阵列。
弹性层的体系结构在很大程度上是可扩展的。弹性层共享存储库路径在 VM HKLM 注册表中为 VDI 和 RDS 工作负载定义。这种设计使得有可能有无限数量的副本来分散负载。
弹性层存储库和用户层共享在设备中定义。弹性层共享在“系统”>“设置和配置”部分中定义。通过修改以下注册表值，可以使用组策略在 VDA 上更改此路径：
HKLM\SOFTWARE\Unidesk\ULayer\RepositoryPath
Value = \\Server\Share
对于大型 VDI 实现，此注册表值允许将多个弹性层存储库用于不同的桌面集。了解有关在注册表中更改弹性层存储库而不重新进行重新设置的详细信息，请参阅 Citrix 文章CTX222107。
用于用户图层的位置由 Active Directory 组分配，因此它也具有高度可扩展性，因为可以根据需要使用尽可能多的共享。这些分配在“系统”>“存储位置”下定义。
有关弹性层共享体系结构的详细信息，请参阅“可用性”、“备份”和“恢复”部分。
用户图层文件共享
在为用户层配置映像的登录过程中，用户层 VHD 文件将在分配给映像后首次登录时创建。用户层共享设置由 Active Directory 组在设备中定义。如果用户处于具有已分配用户层共享的多个组中，则在最高优先级共享上创建共享及其用户层文件的优先级顺序。用户层磁盘一次只能在一台计算机上使用。
用户层同时绑定到登录桌面的域和操作系统层。指向特定用户层的路径，如下所示：
\\Server\Share\Users\Domain_Username\OSLayerID_OSLayerName
用户层是写入密集型的。建议使用针对写入进行优化的文件共享。如果用户层共享与弹性层共享不同，则由 AD 用户组定义的用户分配。
用户层分配在 App Layering 控制台的系统 > 存储位置部分中定义。输入共享和与共享关联的组。
有关弹性层共享体系结构的详细信息，请参阅“可用性、备份和恢复”部分。
App Layering 集成
以下部分概述了 Citrix App Layering 与 Provisioning 系统和虚拟机管理程序的集成。
Citrix App Layering 和 Citrix Provisioning Services
App Layering 很容易与 Citrix Provisioning（PVS）集成。通过在一个或多个 PVS 服务器上安装 App Layering 代理来促进集成。代理提供设备和 Provisioning Services 之间的连接。
上图描述了使用 Citrix Provisioning 发布分层映像的情况。通过从 App Layering 设备发布到 Citrix Provisioning 服务器，集中管理和分发映像以便进行部署。可以创建多种体系结构来支持 Citrix Provisioning。最常用的体系结构是集成用作集成点的单个生产 PVS 服务器。然后，在映像发布时，App Layering 代理将虚拟磁盘下载到 PVS 服务器存储中。代理使用 Windows BITS 服务来执行传输。
发布映像时，可以将连接器 PowerShell 脚本配置为在上传映像后对映像运行。使用此功能时，如果脚本需要处理器密集型，则建议使用不用于执行流式传输的 “预暂存” 预配服务器。这样，发布和脚本处理不会对 Provisioning Services 场中的流式处理功能产生不利影响。为了支持此设计，使用单个服务器创建 “开发” Citrix Provisioning 场是最简单的方法。此 “DEV” 服务器也可用于流式传输测试图像。对映像进行测试后，可将虚拟磁盘复制到生产 Citrix Provisioning 场进行进一步测试和部署。
有关此类脚本的详细信息，请参阅 Citrix 支持文章中的以下示例脚本CTX226060。
将映像发布到 Citrix Provisioning 时，将根据“映像模板名称”对映像进行命名，并附有用于版本控制的日期和时间戳。虚拟磁盘在 Provisioning Services 中的管理方式与不使用 App Layering 的管理方式相同。使用 App Layering 时不使用版本控制。相反，每次发布新映像时都会创建带有新日期和时间戳的完整虚拟磁盘。如果需要对映像进行紧急更改，则可以使用 Citrix Provisioning 版本控制快速修改映像。然后，相同的更改可以添加到相应的层后，问题已经快速解决。
弹性分层对 Citrix Provisioning 缓存磁盘的影响
Citrix Provisioning 使用预留内存和本地连接的缓存磁盘在会话期间临时存储本地文件系统更改。使用 App Layering 和 Citrix Provisioning 时，缓存磁盘大小必须大于不使用 App Layering。无论何时打开文件，对于使用 App Layering 进行写入操作，整个文件都会被复制到虚拟机的可写卷中，以便可以对其进行编辑。当 Citrix Provisioning 通常只会将修改的块复制到缓存中时，也会将整个文件复制到磁盘缓存中。
上图描述了在 Provisioning Server 目标中安装和不安装 App Layering 筛选器驱动程序的缓存磁盘的写入操作。要了解有关使用弹性图层缓存的更多信息，请参阅文章CTX227454。
用户层和 Citrix Provisioning 缓存磁盘
使用用户图层时，在用户登录之前，仅使用 Provisioning 缓存磁盘。
在这种情况下，本地可写分区磁盘仅在启动过程中使用。用户登录后，所有新文件修改都会重定向到文件共享上的 User Layer 磁盘，而不是流虚拟磁盘，这意味着 Provisioning 缓存不再看到可写分区上的 I/O。
Citrix App Layering 和 Machine Creation Services
要将分层映像发布到 Machine Creation Services，请为要发布到的 Hypervisor 创建 Machine Creation Services 连接器。Connector 配置除了主机、存储位置、模板等外，还包括用于访问 Hypervisor 理程序的服务帐户凭据。
然后使用连接器将分层映像作为虚拟机 “主映像” 发布到虚拟机管理程序。
MCS 连接器在发布主映像后启动主映像，并运行已在任何图层中定义的任何图层脚本。运行所有脚本后，必须关闭主映像，并且 Hypervisor 将拍摄虚拟机的快照。完成此过程后，可以使用 Machine Creation Services 部署主映像。虚拟机的命名与 Citrix Provisioning 类似。虚拟机命名为已发布映像模板名称，后跟日期和时间戳。发布新版本的映像时，它是一个新的虚拟机。然后，新虚拟机将用于更新现有目录以推出更改。使用 MCS 时，用于创建主映像的模板必须是从真实虚拟机创建的。计算机已在 Windows 中启动，并设置了正确的时区。此任务可确保正确配置虚拟 BIOS。如果未完成此任务，则生成的启动映像将根据 UTC 的时间延长几个小时。创建模板的最佳方法是使用用于创建操作系统层的原始金色图像的克隆。此步骤可确保虚拟硬件设置从操作系统层到主映像匹配。
Citrix App Layering 跨平台支持
Citrix App Layering 体系结构旨在支持多个虚拟机管理程序和 Provisioning 系统，而无需创建特定于任何一个平台的图层。随着许多组织转向多云或混合云环境，Citrix App Layering 解了这种迁移。
App Layering 支持多个虚拟机管理程序上的多个平台，结合连接器和平台层。
App Layering 连接器-App Layering 连接器是在 node.js 中开发的，从 App Layering 设备运行。这些连接器可以集成到所有受支持的平台，包括虚拟机管理程序和 Provisioning 系统。
平台层 —此层类似于应用程序层，但它始终具有最高优先级，发布图像时清理 “食谱” 对平台层的运行方式与应用层不同。平台层是为定义的 “平台” 安装软件驱动程序的地方。例如，使用 Citrix Provisioning 时，VDA 软件和 PVS 软件都安装在平台层中。
将 App Layering 连接器和平台层组合在一起，以支持可用的平台。了解有关多个虚拟机管理程序和云平台部署详细信息和配置的详细信息，请参阅产品文档。
App Layering 通信流
App Layering 使用很少的连接和端口。这些通信流程记录如下。有关通信的更多信息，请参阅产品文档。
App Layering 设备
App Layering 管理控制台是基于 Microsoft Silverlight 的控制台，通过端口 80 (HTTP) 或 443 (HTTPS) 上的 TCP/IP 访问。
管理设备访问
| 协议 | 端口 |
|---|---|
| HTTP | 80 |
| HTTPS | 443 |
| SSH | 22 |
| 日志下载 | 8888 |
除 HTTP 和 HTTPS 之外，管理员还可以在端口 22 上使用 SSH 直接访问 App Layering 设备虚拟机。不允许在不安全的 Telnet 或 FTP 端口上进行访问。SSH 用于以 “root” 身份登录到设备以获得完全访问权限，“管理员” 帐户用于访问限制菜单以配置网络设置。在 Azure 中，“根”和“管理员”都被禁用。相反，在为本地管理用户帐户设 Provisioning 设备期间，系统会提示管理员。
从管理控制台导出日志时，将生成下载链接并显示在任务详细信息中。端口 8888 用于下载日志。
端口 8161 用于 ActiveMQ 管理和配置，但只能从 App Layering 设备中访问此端口。
或者，App Layering 设备可以检查升级，并使用 HTTPS/443 或 HTTP/80 从 Citrix 服务器上下载它们。如果有互联网连接，则可以访问 m.giftsix.com 和 cdn.n.citrix.com。
Connector 配置
每种连接器类型使用不同的端口。当前连接器列表是：
| 连接器 | 網路端口 | HTTPS 端口 | 内部端口 |
|---|---|---|---|
| Azure | 3000 | 3500 | 3001/3501 |
| Citrix Hypervisor | 3002 | 3502 | 3003/3501 |
| vSphere | 3004 | 3504 | 3005/3505 |
| Nutanix | 3006 | 3506 | 3007/3507 |
| Citrix Provisioning | 3009 | 3509 | 3010/3510 |
| Hyper-V | 3012 | 3512 | 3011/3511 |
连接器在管理控制台中作为单独的网页打开。每个连接器都有一个 HTTP 和 HTTPS 侦听端口。打开连接器后，管理员将被重定向到新选项卡中的基于 HTML5 的界面。管理员的浏览器必须能够在上面列出的每个连接器的端口上访问 App Layering 设备。
其他端口
App Layering 设备与各自端口上的各种网络服务器和服务进行交谈。App Layering 设备连接到以下 TCP 端口上的以下服务：
| 目标位置 | 协议 | 端口 |
|---|---|---|
| Active Directory 服务器 | LDAP（基于 SSL 的 LDAP） | 636 |
| Active Directory 服务器 | LDAP | 389 |
| Active Directory 服务器 | DNS | 53 |
| Windows 文件服务器 | SMB | 445 |
| 网络时间服务器 | NTP | 123 |
| DHCP 服务器 | DHCP | UDP/67 |
| App Layering 设备 | DHCP | UDP/68 |
代理服务
代理服务可用于三个独立的功能：
- 与 Citrix Provisioning 的集成
- 与hyper - v集成
- 与一般脚本服务器集成
代理服务可在以下端口上访问。
| 代理服务器 | 目标 | 函数或协议 | 端口 |
|---|---|---|---|
| 全部 | App Layering 设备 | 注册或 HTTPS | 443 |
| 全部 | 代理服务器 | 来自 App Layering 设备或 SOAP 的命令 | 8016 |
| 全部 | App Layering 设备 | 日志导出 | 8787 |
| Citrix Provisioning | App Layering 设备 | 磁盘上传或 HTTP | 3009 |
| Citrix Provisioning | App Layering 设备 | 磁盘上传或 HTTPS | 3509 |
在初始安装 App Layering 代理时，安装程序在端口 443 上打开与 App Layering 设备的连接以注册代理服务器。App Layering 设备存储代理服务主机的 FQDN 和短名称，代理服务器上的注册表包含 App Layering 设备的记录。
一旦代理和 App Layering 设备交换了身份，App Layering 设备就会在端口 8016 上的安全 SOAP 通道上直接与代理服务进行通信。设备和代理之间的大多数通信工作如下：
| 主机 | 操作 |
|---|---|
| App Layering 设备 | 您好端口 8016 上的代理人 |
| App Layering 设备 | 向代理打开的命令请求 |
| 代理 | 作为配置的用户帐户运行 PowerShell 命令 |
| 代理 | 将回复传输到现有请求频道上的 App Layering 设备 |
| 代理 | 再见 |
正在发送的实际命令的具体细节通常可以在 App Layering 设备上的连接器日志或代理服务服务器上的 Applayer.agent.log 文件中看到。
当要求设备生成日志捆绑时，它会将请求传输到已在设备上注册的每个代理服务，请求来自代理的日志。每个代理服务都会生成自己的日志包，并将其传输回端口 8787 上的 App Layering 设备。
代理服务的主要功能是将文件传输到 Citrix Provisioning 或 Hyper-V。传输文件时，代理使用代理服务服务器上的 Windows 后台智能传输服务 (BITS) 将虚拟磁盘拉到服务器并将其放置在存储中或从 Hyper-V 上上载或下载 VHD。
传输文件的过程是这样的：
| 主机 | 操作 |
|---|---|
| App Layering 设备 | 您好端口 8016 上的代理人 |
| App Layering 设备 | 文件上传的命令请求 |
| 代理 | 作为配置的用户帐户运行 BITS |
| 位 | 在 App Layering 设备上的端口 3009 上打开与 Citrix Provisioning 连接器的连接 |
| 位 | 将文件下载到指定的存储库位置 |
| App Layering 设备 | 获取传输状态的命令 |
| 代理 | 轮询 BITS 的状态并向 App Layering 设备报告 |
| 位 | 完成 |
| 代理 | 向 App Layering 设备报告完成状态 |
通常情况下，文件传输在未加密的端口 3009 上运行。此通信是出于性能原因进行的 — 在 HTTPS 连接上运行的开销会显著影响吞吐量。但是，可以将代理配置为强制使用 HTTPS 并改为使用 3509。
当代理运行 BITS 时，它会提供 BITS 两件事情：用于文件下载的 URL 和目标文件路径。BITS 作为在连接器中配置的用户帐户执行。因此，此用户需要从 Provisioning 服务器到 App Layering 设备上的端口 3009 的传出连接的权限；还需要将文件写入虚拟磁盘存储的权限。
虚拟机管理程序
虚拟机管理程序连接器使用以下端口。
| 连接器 | 目标 | 端口 |
|---|---|---|
| Azure 和 Hyper-V | Azure 管理 | 443 |
| Citrix Hypervisor | Citrix Hypervisor | 5900 |
| vSphere | 虚拟中心 | 443 |
| vSphere | 用于磁盘传输的 ESX 主机 | 443 |
| Nutanix | Nutanix 核查委员会 | 9440 |
这些端口与基于 Hypervisor 浏览器的管理控制台也使用的端口相同。App Layering 通过虚拟机管理程序的普通 Web 服务使用定义明确的 API 调用来与虚拟机管理程序进行通信。
对于 vSphere 文件上传，并且不通过与 vCenter 通信执行下载。并通过与 ESXi 主机的直接通信进行处理。因此，vSphere 连接器需要定义主机，并且必须将主机防火墙配置为允许从端口 443 上的 App Layering 设备进行访问。
合成引擎
合成引擎连接回端口 3260 上的 App Layering 设备以进行 iSCSI 连接，然后它们在端口 443 上对设备进行 API 调用。App Layering 设备也会在端口 443 上对合成引擎执行 API 调用。
可用性、备份和恢复
App Layering 可以包含多个适合备份的组件。包括设备、弹性层共享和用户层共享。
设备备份
如前所述，最终用户不需要使用应用分层设备才能充分使用 App Layering 设备，因此，不需要使设备高度可用。但是，必须将其视为定期备份设备的要求。设备备份可确保所有图层都可用，即使设备以某种方式被破坏或损坏。任何虚拟机备份技术都可用于 App Layering 设备。还可以使用两台设备和导入和导出功能来保持它们同步。但是，这一步现在是一个手动过程。
弹性层的可用性和灾难恢复
弹性层是登录期间使用 SMB 共享的 Windows 客户机内装载安装在虚拟桌面代理 (VDA) 上的文件。分层服务在登录时连接图层，但不会重新连接断开连接的 VHD 文件。因此，通过使用某种类型的群集文件系统，确保用于弹性图层的文件服务器具有高度可用性至关重要。对于此使用案例，使用多个 DFS-R 目标是不够的，因为如果目标出现故障，则无法将挂载的 VHD 文件重新映射到另一个目标，直到发生另一个登录。
对于灾难恢复，有两种模型可用于处理弹性层：复制模型或双设备模型。
参考资料：App Layering 4.x 可用性和恢复概念指南
复制模型
在此模型中，可以使用任何文件系统复制技术复制弹性层共享。此模型可以包括技术，如 DFS-R、Microsoft Storage Replica、Veeam，NAS 供应商复制、Zerto、VMware vSphere 复制，甚至机器人副本。
然后，可以通过 GPO 将 DR 数据中心中的 VDA 指向该数据中心中的弹性层共享。配置存储库位置的 GPO 模板可以在此处找到：CTX222107。
双电器型号
在此模型中，每个数据中心都安装了一个设备。设备提供的导入和导出功能用于从图层角度保持两个设备的同步。在这里，管理员可以单独管理 DR 图层，并从本地设备在 DR 中构建映像。
如果选择此选项，则同步通过 WAN 从导入和导出操作期间定义的 SMB 共享传输。然后，必须在 DR 设备上分配图层将其复制到 DRR 中的弹性图层共享。在这个模型中，还可以开发一个解决方案，不同步所有层，而只同步所需层。由于图层是手动导出的，因此只能将所选图层包含在过程中。目前，导入和导出过程必须手动启动。
在双设备模型中，必须在每一侧创建弹性共享的连接器和权限。导入的唯一对象是实际图层本身。但是，在此模型中，可以根据需要在每个站点中具有不同的图层。例如，如果它实际上是一个主动-主动站点场景。
用户层的可用性和灾难恢复
用户层类似于弹性层，因为它们是 Windows 在登录时使用客户机装载安装的 VHD 文件。但是，它们以可写的方式装载，并且文件被 Windows 桌面锁定。此任务使备份和复制这些磁盘的选项比普通弹性层更加困难。
由于此限制,如果使用DFS-R或robocopy脚本,则必须在小时以外执行同步过程(如果有时间被视为关闭小时）。该过程必须不断检查文件是否可用于同步。对于用户层，它可以是大文件，robocopy 将无法正常工作，因为它总是复制整个文件而不是已更改的块。DFS-R 将是一个更好的选择，因为它只复制修改的块。但是，存储级别的复制会更好，因为它会在进行更改时更均匀地同步，而不是等待删除文件锁。
此处还支持其他选项，具体取决于用于存储用户层 VHD 文件的技术。如果文件服务器支持卷影复制服务 (VSS)，则会创建 VSS 快照以允许备份和复制用户层。如果损坏或错误对用户产生不利影响，则通过改变过程的频率，用户层也可以回滚到较早的时间点。
如果存储 Controller 支持 NDMP，则此功能也可用于用户层备份。NDMP 在存储级别工作，利用 NAS 快照将 NAS 存储直接备份到磁盘或磁带。
由于复制大型磁盘的困难以及复制带宽的费用，许多客户选择为没有复制用户层的用户提供 DR 桌面。在此模型中，有两个选项。用户可以在 DR 站点中配置一个单独的交付组，该交付组也启用了用户层。然后，他们可以登录到 DR 站点，并根据所需内容预先配置该层。或者，可以使用普通的非持久性 DR 桌面来配置用户。在后一种情况下，将 Citrix 配置文件管理与用户层混合起来通常是有益的，以便可以将用户设置复制到 DR 站点。
参考资料：Citrix App Layering 备份和恢复
来源
此参考体系结构的目标是帮助您规划自己的实施。为了简化这项任务，我们希望为您提供源图，您可以在您自己的详细设计和实施指南中进行调整：源图。
引用
为了更好地了解 Citrix App Layering，引用了以下资源：