参考体系结构：App Layering
受众
本文档面向技术专业人员、IT 决策者、合作伙伴和系统集成商。这将允许管理员探索并采用 Citrix App Layering 来帮助管理向最终用户交付的映像和应用程序。读者必须基本了解 Citrix 产品、映像管理服务和应用程序虚拟化概念。有关映像管理的更多信息，请参阅 CitrixTech Zone参考体系结构。
本文件的目标
本文档提供了使用 Citrix App Layering 技术管理和交付应用程序的技术概述和体系结构概念。本文档包括App Layering 的工作原理以及与不同平台上的 Citrix Virtual Apps and Desktops 的集成。
Citrix App Layering 概述
Citrix App Layering 是一种灵活的解决方案，可在任何非持久支持的平台上为各种用户提供一组复杂的 Windows 应用程序。
Citrix App Layering 以独特的方式执行图像管理。操作系统和应用程序被拆分为不同的容器，称为“Layers”。层将独立创建和更新，然后将其编译成“已发布映像”，以便使用任何受支持的配置系统进行分发。
创建应用程序库后，将使用任意图层组合将不同的映像集部署到多个平台。
Citrix App Layering 的主要目标是使用单一界面简化 Windows 应用程序管理。它允许管理员创建和管理企业应用程序，而不管底层的虚拟机管理程序或云基础体系结构如何。
操作系统和应用程序分为独立的可管理单元。即使需要多个映像才能正确控制应用程序访问，每个操作系统及其应用程序都会作为一个实例进行管理。在这种方法中，不必对环境中的每个映像执行更新。简化环境，同时减少与操作系统和应用程序管理相关的管理时间、复杂性和成本。
操作系统和应用程序存储为虚拟磁盘，其中包含特定层的文件和注册表项。有两种方法可以在虚拟机中包含应用程序：
- 已发布映像：此方法将操作系统层、平台层和一组应用程序层组合在一起，为预配系统（如 Citrix Provisioning 或 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 一起使用的预配模型和第三方虚拟机管理程序。使用 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 可以支持具有内核驱动程序、系统服务、第三方驱动程序和控制台访问的复杂应用程序。由于，App Layering 的两种应用层部署模式几乎所有应用程序都兼容。
非持久性桌面用户层：用户层是可写的弹性层。用户登录到桌面，大多数写入操作都进入用户层。它允许用户安装应用程序并保存用户配置文件之外的配置设置。此外，它还通过使用户的桌面看起来像是持久性的，并具有共享桌面模型的好处来存储用户的数据文件。
减少所需映像的数量：Elastic Layering 可以在登录时仅向分配的用户动态交付应用程序，从而显著减少所需映像的数量。Citrix DaaS弹性层与 Citrix Virtual Apps 和 Citrix Virtual Desktops 兼容。
Citrix App Layering 使用案例
App Layering 是 Citrix 技术组合的重要补充，它提供了上面列出的许多好处。尽管它提供了好处，但App Layering 并不意味着在所有用例中都使用它。在本节中，概述了几个最相关的使用案例，以展示 App Layering 技术的优势。
1-要管理的映像太多
许多 Citrix 客户必须支持大量应用程序和一组复杂的用户要求。使用基于映像的资源调配技术时，满足这些要求通常需要管理大量映像。这些映像必须支持不同的用户组或不同的冲突应用程序集。部署到每个映像的应用程序通常也会有一些重叠。
Citrix App Layering 简化了这种复杂方案的管理。
App Layering 允许管理员将操作系统和应用程序作为使用层的单个实体进行管理。例如，需要修补 Windows，对操作系统层进行一次修补，所有使用操作系统层的映像都由 App Layering 设备更新。如果在 10 个映像中使用了 Microsoft Office，则通过向 Office 层添加一个版本，升级此 Office 会更简单。最终，所有这10张图像都会自动更新。
添加弹性分层后，也可以显著减少所需图像的数量。弹性层允许管理员在登录期间动态交付应用程序。对于并非所有人都使用的应用程序，Elastic Layers 允许更通用地创建映像，同时为每个用户提供自定义设置。
2-支持多个虚拟机管理程序和 Azure
许多组织正在转向混合本地和云资源的混合多云环境，以增强用户体验。Citrix App Layering 通过为每个所需环境创建不同的平台层来支持大多数虚拟机管理程序和 Microsoft Azure，从而提供映像可移植性。
通常，混合管理 Hypervisor 和混合云配置会迫使管理员在多个不同的管理平台中维护多组不同的映像和应用程序。借助 App Layering 技术，可以将本地使用的相同操作系统和应用程序推送到云端或其他虚拟机管理程序，而无需进行额外工作。
要了解App Layering 跨平台功能，请参阅下面的Citrix App Layering 跨平台支持部分。
3- 适用于迁移的虚拟机管理程序可移植性
企业通常会“困扰”供应商的技术，仅仅是因为迁移到新技术的成本太高。此外，公司经常与作出不同技术选择的其他组织合并。App Layering 的一个明显优势是可以通过创建不同的平台层，并通过导入导出将 App Layering 设备迁移到新平台，从一个平台移动到另一个平台。
允许无缝迁移，例如，从 vSphere 到 Citrix Hypervisor 或从本地虚拟机管理程序迁移到 Azure。
共享 VDI 桌面的4-持久性
许多组织有多个用户需要在桌面上保持高水平的持久性。包括任何组中的高级用户、开发人员、工程师、体系结构师等。App Layering 用户层在池桌面体系结构之上提供了大量的持久性。
用户层在登录时挂载，桌面上的任何后续写入都将写入用户层。大多数应用程序都可以安装在用户层中。在用户层中起作用的规则与弹性分层的规则相同。只要应用程序不安装内核驱动程序、第三方驱动程序以及在引导过程中依赖于其他服务的服务，它们最有可能在用户层中工作。
对于需要持久性的用例，用户层是最佳选择。对于仅支持 Microsoft Outlook OST 文件和索引文件的使用案例，用户层可能不是最佳选择。用户层旨在处理用户登录后对 VDI 桌面的所有写入操作。其他技术，例如 Citrix Profile Management 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。从虚拟机管理程序中的“黄金映像”虚拟机构建。
平台层：平台层包括支持特定平台所需的软件。如果虚拟机管理程序与默认虚拟机管理程序不同，则包括代理代理、预配系统和虚拟机管理程序工具。平台层也是最高优先级的层，有时会在此处安装软件，以便以最高优先级进行编译。
应用程序层：主图层类型。用于大多数应用程序软件。
用户层：弹性（参见下一节）可写层。用户层在登录时挂载，一旦挂载，几乎所有桌面写入都将进入用户层。此层使用户能够显著自定义其 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 共享接口，以支持设备升级过程和存储弹性层。
该设备仅用于管理图层、图像和弹性层分配。虚拟桌面和虚拟应用程序服务器不直接与设备交互。弹性分配图层时，设备会将该图层复制到弹性层共享。共享包含这些 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 用于附加 App Layering 设备上托管的磁盘
- 同时发布作业的数量没有限制（实际上有限制）
合成引擎的优势
使用合成引擎是一种选择。在 HyperV 连接器和 vSphere 连接器中，有一个复选框用于启用“卸载合成”。此设置在 vSphere 的计算机创建和 VMware Horizon View 连接器中也可用。合成引擎的显著优势是它运行在可直接访问虚拟机管理程序磁盘的 Windows 设备上。这提供了支持 HyperV、本机 ESX VMDK 格式的 GEN2 计算机的机制，并在 vSphere 和 UEFI 中使用精简资源调配。打包和发布性能得到了增强，因为合成引擎处理较少，然后由合成引擎连接回 App Layering 设备以使用 iSCSI 连接访问层，直接写入虚拟机管理程序上的磁盘。
注意：PVS 发布尚不能使用合成引擎执行，因此仍然无法将 VHDX 文件或 GEN2 虚拟机直接发布到 PVS。
图层交付
图层可以通过两种方式交付。作为已发布映像的一部分，App Layering 设备将所有图层合并到单个磁盘文件中，然后将该文件上载到 Provisioning 备系统，或者在登录时装载图层并动态供用户使用。
已发布映像：在这里，操作系统、平台和应用程序层集合并为一个磁盘文件，该文件发布到 Citrix Provisioning 或 Machine Creation Services 等预配系统。该过程首先克隆操作系统层，然后按优先级顺序从应用程序层逐一写入文件，层越新，优先级越高，最后写入平台层。创建已发布图像的合并过程是高级的。创建映像时，将合并文件系统、注册表和环境变量，重新创建 Windows 驱动程序存储区，合并来自不同层的所有第三方驱动程序。
弹性层：这些层是通过 Active Directory 群组成员资格分配给用户的应用程序层，并在登录期间或登录后稍稍附加这些层。弹性层是动态的，允许管理员自定义用户体验，同时最大限度地减少图像数量。
连接器和连接器配置
App Layering 设备使用连接器与虚拟机管理程序和预配系统集成。
连接器有两种类型-虚拟机管理程序和配置：
虚拟机管理程序连接器提供了与虚拟机管理程序接口的机制。目前，有适用于 Citrix Hypervisor、vSphere、Hyper-V、Nutanix AHV、Azure 和 Azure 政府的虚拟机管理程序连接器
Provisioning 系统连接器允许管理员将映像发布到置备系统。目前，在每个虚拟机管理程序和 Horizon View 上都有适用于 Citrix Provisioning 的 Provisioning 系统连接器、Citrix Machine Creation Services
通过定义更多连接器，单个设备可以连接到任意数量的虚拟机管理程序或 Provisioning 备系统。连接器配置定义了与虚拟机管理程序或预配系统集成所需的设置。配置通常包括用于身份验证的凭据、存储位置、虚拟机模板以及与管理员创建图层或发布映像的环境进行交互所需的任何其他信息。管理员可以创建多个连接器配置，每个配置都配置为访问环境中的唯一位置。连接器用于：
- 创建操作系统层时导入黄金映像
- 创建图层和图层版本
- 将分层映像发布到虚拟机管理程序或预配服务。连接器配置还可以包括在 Provisioning Server 上运行的 PowerShell 脚本，也可以包括具有主机代理的系统上运行的 PowerShell 脚本，以便对已发布映像执行后处理
参考：连接器配置
连接器类型
本节定义了 Citrix App Layering 中可用的连接器类型。
虚拟机管理程序连接器
在创建层或导入 Gold Image 以创建操作系统层时使用虚拟机管理程序连接器。虚拟机管理程序连接器在打包时会在连接器配置定义的存储和主机上动态创建打包机。虚拟机管理程序连接也可用于在虚拟机管理程序中创建虚拟机。
Citrix Provisioning
Citrix Provisioning 连接器与 Citrix Provisioning 服务器上的App Layering 代理集成，可将映像作为虚拟磁盘直接发布到 Provisioning 服务器。Citrix Provisioning 的必备条件是：
- 连接器服务帐户必须是在 PVS 中具有管理员权限的域帐户。
- 连接器服务帐户还必须是 Citrix Provisioning 服务器上的本地管理员。
- 必须在连接器中定义的每台 Citrix Provisioning 服务器上安装 Citrix App Layering 代理。每个连接器只能定义一个代理。
机创建服务
Citrix App Layering 设备可以将分层映像作为用作 MCS 主映像的虚拟机直接置备分层映像并将其发布到虚拟机管理程序。连接器允许将分层图像直接发布到虚拟机管理程序。MCS 连接器与 Hypervisor 连接器几乎完全相同，不同之处在于 MCS 连接器启动已发布的虚拟机，允许在层中定义的任何脚本在 MCS 部署主映像之前在主映像上运行。在此过程中，主映像关闭和虚拟机快照拍摄。
连接器脚本
此步骤是创建连接器配置时可用的可选高级功能。要使用此功能，请配置一个可选的 PowerShell 脚本，使其在连接器配置中定义的代理服务器上运行。此步骤最常用于 Citrix Provisioning，但可以通过在 Windows 系统上安装 App Layering Agent 来针对已发布的映像运行脚本来与任何其他发布连接器一起使用。将脚本复制到安装代理的计算机上。此脚本在成功部署分层映像后运行。要使用此功能，对于虚拟机管理程序上的主映像，脚本还必须与虚拟机管理程序的管理平台接口。例如，对于 vSphere，该脚本需要对 vCenter 使用 PowerCLI 才能对主映像虚拟机运行代码。
通过某些预设变量，可以使用不同的模板映像和不同的连接器配置来重复使用脚本。变量还包含将虚拟机识别为已发布映像的一部分的信息。
要了解有关示例脚本的更多信息，请参阅以下支持文章CTX226060和CTX226062。
已发布的图像模板
使用App Layering 时，App Layering 设备会合并操作系统、平台和应用程序层以创建已发布的映像。映像将按照目标置备系统要求的格式发布，然后创建。例如，如果管理员发布到 Citrix Provisioning，则设备会创建 VHD 并将其作为虚拟磁盘上载到定义的配置服务器。如果解决方案在 Citrix Hypervisor 拟机管理程序上使用 Machine Creation Services，则设备将创建 VHD，将其上载到 Citrix Hypervisor 并使用 VHD 创建主映像 VM。
要定义已发布映像的配置，需要使用映像模板。映像模板定义映像中包括哪些操作系统、平台和应用程序层。它还定义了用于发布图像的连接器、生成的图像的大小（以 GB 为单位）、映像是否启用了 Elastic Layering 还是不同类型的用户层之一。映像模板是映像配置的时间点快照，它们不支持版本控制。但是，如果需要同一映像的版本略有不同，则可以克隆和修改映像模板。
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++ 运行时库）都作为操作系统映像的一部分包括在内。
最好不要将最终用户应用程序安装到操作系统层，因为使用特定操作系统层创建的所有应用程序层都与该操作系统层相关联。如果应用程序安装在操作系统层中，则使用该层将该应用程序包含此过程的每个映像都会导致在策略是使操作系统层通用时出现问题。将应用程序与操作系统分开是限制要管理的操作系统映像数量的关键。即使是带有驱动程序、服务和内核设备的应用程序也受应用程序层的支持，不需要包含在操作系统层中。
在创建操作系统层的过程中，有几点需要记住：
- 从链接中查看支持的操作系统
- 操作系统层未连接到域。域加入是平台层的一部分
- 主虚拟机管理程序的虚拟机管理程序工具安装在操作系统层中。执行大多数打包的虚拟机管理程序
- 备用虚拟机管理程序的虚拟机管理程序工具安装到该虚拟机管理程序的平台层中
- 在操作系统层安装.NET 组件（来自 Microsoft）和更新
- 如果需要 Microsoft 运行时，它们将安装在操作系统层中
- Windows 角色和功能，例如安装在操作系统层中的 RDS 角色，以便可以使用 Windows 更新对其进行更新
- 如果需要将本地用户或组添加到虚拟机，则此任务只能在操作系统层中完成，因为 Windows 安全帐户管理器 (SAM) 从操作系统层捕获
参考：创建操作系统层
平台层
平台层是包含在特定平台上运行已发布映像所需的配置设置、工具和其他软件的层。可以创建两种平台层类型：
发布平台层：这种类型的平台层用于包括目标预配系统、代理和虚拟机管理程序所需的软件。例如，用于支持适用于 Citrix Virtual Apps 的 vSphere 上的 Provisioning Services 的发布平台层已安装 Citrix VDA 和 PVS 设备驱动程序。如果 vSphere 不是执行打包的同一个虚拟机管理程序，则此层还安装了 VMware Tools。
包装平台层：如果需要包装层来支持包装机，则使用包装平台层。这些层通常不是必需的，但有几种情况必须是必需的，包括：
如果图层必须打包在与标准虚拟机管理程序不同的虚拟机管理程序上。例如，如果大多数层是在 Hyper-V 上创建的，但由于某种原因，在 vSphere 中创建了特定层，则使用带有 VMware Tools 的打包平台层来支持 vSphere 上的打包机。
如果需要使用 VDA 软件访问包装机。为 USB 外围设备安装驱动程序时，通常需要此层，这些驱动程序必须看到设备才能正确安装。通过创建安装了 VDA 软件的打包平台层并将打包计算机添加到 Studio 中手动置备的目录中，可以支持这种类型的访问。
创建平台层
关于平台层的创建，需要记住以下几点：
- 对于 Citrix Provisioning，在不运行映像向导的情况下安装目标设备软件，然后重新启动
- Citrix VDA 和 Citrix Provisioning 设备驱动程序的安装在平台层进行
- 域加入是在平台层执行的，这意味着可以创建多个平台层来支持不同的域
- 平台层也是最高优先级层，因此可以安装一些可选组件，包括诸如 Imprivata 之类的 SSO 软件、备用虚拟机管理程序的管理程序工具以及 Citrix Workspace Environment Management Agent。
要了解有关平台层创建的更多信息，请参阅文章CTX225997。
应用程序层
应用程序层用于打包大多数应用程序。应用程序层包含应用程序或应用程序组的文件系统和注册表对象。创建或编辑层时，会动态创建打包机，并在该计算机上捕获所有文件系统和注册表更改。打包机包含操作系统层和任何包含的必备应用程序层。另一个名为 Package Disk 的虚拟磁盘作为可写卷连接到打包机。该磁盘捕获打包期间的所有文件系统更改，并且还包含用于捕获所有注册表更改的注册表配置单元（称为 RSD 配置单元）。打包机完成后，仅下载软件包磁盘。启动磁盘已被删除。
要了解有关创建和编辑应用程序层的更多信息，请参阅产品文档。
大多数情况下，应用程序的安装配置与管理员通常用于支持的 Provisioning 系统的配置相同。在创建 App Layer 时，务必设法禁用自动更新。因为管理员通常不希望应用程序在部署后自动更新。Citrix 已经记录了一些常见应用程序的分层过程. 这些 App Layering“配方”可以在以下链接中找到。
弹性分层
弹性分层是一种在用户登录期间将应用程序动态部署到虚拟会话的方法，方法是将存储为 VHD 文件的层安装在 SMB 共享上，然后使用 Citrix 复合文件系统 (CFS) 将其集成到文件系统中。弹性分层由 Citrix 分层服务在 VDA 上进行管理。弹性层存储库是一个 SMB 共享，其中包含层 VHD 文件和 JSON 配置文件，用于定义分层服务的层分配。分层服务读取配置文件，然后使用 WindowsSDK 调用挂载层 VHD 文件。
弹性分层技术不支持所有应用程序，因为弹性层是在登录时挂载的。以下应用程序要求将应用程序排除在弹性层中使用：
- 带有内核驱动程序的应用程序
- 具有依赖于其他启动时服务的服务的应用程序
- 修改 Windows 驱动程序存储的应用程序，如第三方打印机驱动程序
具有这些要求的应用程序可以分层，但图层必须包含在发布的映像中。
配置文件 (JSON)
如上所述，弹性层分配是在弹性层存储库中存储的一组 .JSON 文件中定义的。这些文件的定义如下：
ElasticLayerAssignment.json：此文件包含有关用户和组映射到应用程序层的信息。此文件包含已分配应用程序的每个组或用户 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\Etc\UserLayer.json 文件中，作为“IndexerHash”。在后续登录时，将此字符串与重新计算的 IndexerHash 进行比较，只有在它们不同时，才重新构建抓取范围。
可以使用以下类型的用户图层：
- 完整：用户的所有数据、设置和本地安装的应用程序都存储在其用户层
- Office 365：只有用户的 Outlook 数据和设置存储在用户层中。每次登录都会重新创建搜索索引。
- 会话 Office 365：只有用户的 Outlook 数据和设置存储在用户层中。每次登录都会重新创建搜索索引。
注意：如果使用 Office 365 层，建议使用 Citrix Profile Management来保留 Outlook 设置。
用户图层的默认最大大小为 10 GB。可以通过为用户层共享定义配额来更改此大小。也可以使用 VDA 上的注册表项覆盖默认的用户层最大大小。要更改默认最大大小，请添加以下注册表覆盖：
HKLM\Software\Unidesk\ULayer\
DWORD: DefaultUserLayerSizeInGb
VALUE:
弹性层共享和用户层共享
弹性层是由客户端或服务器操作系统通过 VM 网络挂载的 VHD 文件。弹性层以只读方式挂载，许多机器可以挂载完全相同的 VHD 文件。用于弹性层的文件服务器或共享已针对读取 I/O 进行了优化。
用户层是可写的弹性层。用户层只能由单个桌面进行读/写挂载。用于用户层的文件服务器或共享已针对写入 I/O 进行了优化。使用用户层时，存储的性能对用户体验至关重要。强烈建议将闪存阵列用于用户层共享。
弹性层的体系结构在很大程度上是可扩展的。弹性层共享存储库路径在 VDI 和 RDS 工作负载的 VM HKLM 注册表中定义。这种设计使得有可能有无限数量的副本来分散负载。
弹性层存储库和用户层共享在设备中定义。弹性层共享在“系统”>“设置和配置”部分中定义。通过修改以下注册表值，可以使用组策略在 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 与预配系统和虚拟机管理程序的集成。
Citrix App Layering 和 Citrix Provisioning 服务
App Layering 很容易与 Citrix Provisioning (PVS) 集成。通过在一个或多个 PVS 服务器上安装 App Layering Agent 来促进集成。代理提供设备和 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，请使用为要发布到的虚拟机管理程序创建的 Machine Creation Services 连接器。Connector 配置除了主机、存储位置、模板等外，还包括用于访问 Hypervisor 理程序的服务帐户凭据。
然后使用连接器将分层映像作为虚拟机“主映像”发布到虚拟机管理程序。
MCS 连接器在发布主映像后启动主映像，并运行已在任何图层中定义的任何图层脚本。运行完所有脚本后，必须关闭主映像，虚拟机管理程序将拍摄虚拟机的快照。完成此过程后，可以使用 Machine Creation Services 部署主映像。虚拟机的命名与 Citrix Provisioning 类似。虚拟机以发布的映像模板名称命名，后跟日期和时间戳。发布新版本的映像时，它就是新的虚拟机。然后，新的虚拟机将用于更新现有目录以推出更改。使用 MCS 时，用于创建主映像的模板必须是从真实的虚拟机创建的，这一点很重要。计算机已在 Windows 中启动并设置了正确的时区。此任务可确保正确配置虚拟 BIOS。如果未完成此任务，生成的引导映像将根据 UTC 关闭几个小时。创建模板的最佳方法是使用用于创建操作系统层的原始黄金映像的克隆。此步骤可确保从操作系统层到主映像的虚拟硬件设置都匹配。
Citrix App Layering 跨平台支持
Citrix App Layering 体系结构旨在支持许多虚拟机管理程序和预配系统，而无需创建特定于任何一个平台的层。随着许多组织转向多云或混合云环境，Citrix App Layering 解了这种迁移。
App Layering 支持多个虚拟机管理程序上的多个平台，结合连接器和平台层。
App Layering Connector-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 进行访问。
管理设备访问权限
| 协议 | Port（端口） |
|---|---|
| HTTP | 80 |
| HTTPS | 443 |
| SSH | 22 |
| 日志下载 | 8888 |
除了 HTTP 和 HTTPS 之外，管理员还可以在端口 22 上使用 SSH 直接访问 App Layering 设备虚拟机。不允许在不安全的 Telnet 或 FTP 端口上进行访问。SSH 用于以“root”身份登录到设备以获得完全访问权限，“管理员”帐户用于访问限制菜单以配置网络设置。在 Azure 中，“根”和“管理员”都被禁用。相反，在设备置备期间，系统会提示管理员输入本地管理用户帐户。
从管理控制台导出日志时，将生成一个下载链接并显示在任务详细信息中。端口 8888 用于下载日志。
端口 8161 用于 ActiveMQ 管理和配置，但只能在App Layering 设备中访问此端口。
或者，App Layering 设备可以检查升级情况，然后使用 HTTPS/443 或 HTTP/80 通过互联网从 Citrix 服务器下载升级。如果有互联网连接，则可以访问 m.giftsix.com 和 cdn.citrix.com。
Connector 配置
每种连接器类型使用不同的端口。当前的连接器列表是：
| 连接器 | HTTP 端口 | HTTP 端口 | 内部端口 |
|---|---|---|---|
| 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 端口连接到以下服务：
| 目标 | 协议 | Port（端口） |
|---|---|---|
| Active Directory 服务器 | LDAPS (通过 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集成
- 与通用脚本服务器集成
可以通过以下端口访问代理服务。
| 代理服务器 | 目标 | 功能或协议 | Port（端口） |
|---|---|---|---|
| 全部 | 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 设备上的连接器日志或代理服务服务器上的 applayering.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 建立传出连接；还需要将文件写入虚拟磁盘存储的权限。
虚拟机管理程序
虚拟机管理程序连接器使用以下端口。
| 连接器 | 目标 | Port（端口） |
|---|---|---|
| Azure 和 Hyper-V | Azure 管理 | 443 |
| Citrix Hypervisor | Citrix Hypervisor | 5900 |
| vSphere | 虚拟中心 | 443 |
| vSphere | 用于磁盘传输的 ESX 主机 | 443 |
| Nutanix | Nutanix CVM | 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 可以有多个适合备份的组件，包括设备、弹性层共享和用户层共享。
注意：
虽然本节介绍连接代理的可用性，但此处不介绍 VDI 代理基础体系结构的恢复和可用性。有关桌面连接代理软件的恢复选项的详细信息，请参阅您的桌面连接代理软件的文档和支持团队。
App Layering 的任何可用性策略都必须与整个工作空间解决方案的整体可用性和恢复设计相吻合。池和交付组已经具有高可用性，因为它们分布在主机和存储池中。
存储可以通过不同的方式实现高可用性。一种常见的方法是使用具有高度冗余的存储阵列，包括多个存储处理器或磁头以及 RAID 技术。但是，也可以使用基于本地 RAID 控制器的本地存储和每台主机上的烧瓶磁盘，并在主机之间分布托管计算机，从而获得更高的可用性。如果主机因任何原因出现故障，其他主机将使用可用桌面池中的托管计算机运行，以获取用户会话。
由于虚拟机管理程序在设计时考虑了可用性，因此网络也易于使用。但是，确保环境中的每台托管计算机至少有两条网络路径可用，这一点很重要。
特定于App Layering 的组件包括设备层、弹性层和用户层。
设备备份
如前所述，最终用户不需要使用 App Layering 设备才能充分使用 App Layering 设备，因此，不需要使设备高度可用。但是，必须将其视为定期备份设备的要求。设备备份可确保所有层都可用，即使设备以某种方式被破坏或损坏。任何虚拟机备份技术都可以用于 App Layering 设备。也可以使用两个设备以及导入和导出功能来保持它们同步。但是，此步骤现在是手动过程。
弹性层的可用性和灾难恢复
弹性层是在登录时使用 SMB 共享的 Windows 客户机内装载在虚拟桌面代理 (VDA) 上挂载的文件。分层服务在登录时连接图层，但从不重新连接断开连接的 VHD 文件。因此，通过使用某种类型的群集文件系统来确保用于 Elastic Layers 的文件服务器的高可用性至关重要。对于此用例，使用多个 DFS-R 目标还不够，因为如果目标出现故障，则在再次登录之前，无法将装载的 VHD 文件重新映射到另一个目标。
对于灾难恢复，有两种模型可用于处理弹性层：复制模型或双设备模型。
复制模型
在此模型中，可以使用任何文件系统复制技术复制弹性层共享。此模型可以包括技术，如 DFS-R、Microsoft Storage Replica、Veeam，NAS 供应商复制、Zerto、VMware vSphere 复制，甚至机器人副本。
然后，可以通过 GPO 将 DR 数据中心中的 VDA 指向该数据中心中的弹性层共享。可以在此处找到用于配置存储库位置的 GPO 模板：CTX222107。
双电器型号
在此模型中，每个数据中心都安装了一台设备。设备提供的导入和导出功能用于从层的角度使两台设备保持同步。在这里，管理员可以单独管理 DR 图层，并从本地设备在 DR 中构建映像。
如果选择此选项，则同步通过 WAN 从导入和导出操作期间定义的 SMB 共享传输。然后，必须在灾难恢复设备上分配层，将它们复制到 DR 中的弹性层共享在此模型中，还可以开发一种解决方案，该解决方案不会同步所有层，而只同步所需的层。由于图层是手动选择导出的，因此只能将选定的图层包括在流程中。目前，必须手动启动导入和导出流程。
在双设备模式中，必须在每侧创建弹性共享的连接器和权限。唯一被导入的对象是实际的层本身。但是，在此模型中，可以根据需要在每个站点中使用不同的图层。例如，如果它确实是一个主动-主动站点场景。
用户层的可用性和灾难恢复
用户层与弹性层类似，因为它们是 Windows 在登录时使用客户机内挂载挂载挂载的 VHD 文件。但是，它们被装载为可写文件，并且文件被 Windows 桌面锁定。此任务使得备份和复制这些磁盘的选项比普通的弹性层困难得多。
由于此限制，如果使用 DFS-R 或 robocopy 脚本，则必须在非工作时间（如果有非工作时间）执行同步过程。该过程必须不断检查文件是否可以同步。对于用户层（可能是大文件），robocopy无法正常工作，因为它总是复制整个文件而不是已更改的块。DFS-R 将是一个更好的选择，因为它只复制修改过的块。但是，存储级别的复制会更好，因为在进行更改时同步会更加均匀，而不是等待文件锁被删除。
此处还支持其他选项，具体取决于存储用户层 VHD 文件所选择的技术。如果文件服务器支持卷影复制服务 (VSS)，则会创建 VSS 快照以允许用户层的备份和复制。通过改变流程的频率，如果发生对用户产生不利影响的损坏或错误，用户层也可以回滚到更早的时间点。
如果存储控制器支持 NDMP，则此功能也可用于用户层备份。NDMP 在存储级别使用 NAS 快照将 NAS 存储直接备份到磁盘或磁带。
由于复制大型磁盘的难度以及这样做的带宽开支，许多客户选择为没有复制用户层的用户提供灾难恢复桌面。在此模型中，有两个选项。可以在 DR 站点中为用户配置单独的交付组，该交付组也已启用“用户层”。然后，他们可以登录灾难恢复站点，并使用所需的内容预配置该层。或者，用户可以使用普通的非持久性 DR 桌面进行配置。在后一种情况下，将 Citrix Profile Management与用户层混合起来通常是有益的，以便可以将用户设置复制到 DR 站点。
组件多站点灾难恢复
多站点灾难恢复的方法类似于本地恢复。对于映像，必须使用复制过程。如果您使用的是 Citrix Provisioning，则可以使用 Robocopy 将虚拟磁盘复制到辅助站点。如果您在 vSphere 上使用 Machine Creation Services 或 Horizon View，则需要一个流程来复制虚拟机，例如 Veeam、Zerto、VMware vSphere Replication 或 Site Recovery Manager。这也起到了保护榆树的作用。
对于“弹性层”，SAN 复制或脚本化拷贝都可用。如果您使用的是用户层，则需要在 SAN/NAS 级别进行复制，以便可以在用于共享的群集文件系统下复制更改的数据块。
这种方法比在 ELM 中定义多个连接器并直接发布到两个站点要好，因为在发布时，您必须同时合成映像并将其上传到应用商店。如果使用复制已创建映像的进程，则会跳过合成过程，效率更高。
注意：
如果您希望为部署到灾难恢复的映像使用不同的配置，则最好直接从 ELM 发布。这允许您在映像模板中定义不同的图层以进行恢复。
也可以使用两台 ELM 设备，每个站点一个。然后，您可以使用导出/导入功能从图层角度使这些 ELM 保持同步。然后，您可以单独处理恢复，并从本地 ELM 在那里构建映像。
如果选择此选项，则同步将通过 WAN 传输到“设置”中定义的 SMB 共享。然后，使用带有 /MIR 开关的 Robocopy，可以将图层同步到第二个站点中使用的 SMB 共享。目前，导入和导出过程必须手动启动。
您也可以只同步所需的图层，而不是同步所有图层。如果您希望使用此选项，请联系您的 App Layering 解决方案体系结构师了解更多详情。
在双 ELM 模型中，必须在每侧创建弹性共享的连接器和权限。导入的唯一对象是实际的层。但是，在此模型中，可以根据需要在每个站点中使用不同的图层。
来源
此参考体系结构的目标是帮助您规划自己的实施。为了简化此任务，我们想为您提供源图，您可以在自己的详细设计和实施指南中进行调整：源图。
引用
为了更好地理解 Citrix App Layering，参考了以下资源：