部署指南：在 Microsoft Azure 上将 Citrix Virtual Apps and Desktops 从 VMware vSphere 迁移到 Citrix DaaS

概述

在本文档中，您将了解如何从 VMware vSphere 上的 Citrix Virtual Apps and Desktops 迁移到 Microsoft Azure 上的 Citrix DaaS。迁移到云资源可实现部署的现代化，提供增强的弹性、可扩展性和管理能力。

此处记录的指南基于在经 Citrix 和 Microsoft 审查和批准的实验室环境中的部署。初始和最终部署代表典型的客户环境。

我们迁移了这些关键产品和组件：

• Citrix DaaS 本地的 Citrix Virtual Apps and Desktops
• Workspace Environment Management 本地到 Workspace Environment Management
• 本地 StoreFront 和 Citrix Gateway 到 Citrix Workspace 和 Citrix Gateway 服务
• Azure 中工作负载的本地 vSphere 工作负载
• 将本地文件服务器转到 Azure
• Azure 中的 Citrix 工作负载

下图显示了迁移过程。

最佳迁移路径

根据我们的经验和测试，最佳迁移路径遵循以下步骤：

1. 设置基本的 Citrix Cloud 环境。
2. 使用 Citrix 开发的自动配置工具将本地 Citrix Virtual Apps and Desktops 迁移到 Citrix DaaS。
3. 将本地Workspace Environment Management 迁移到Workspace Environment Management 服务。
4. 配置最终用户接入层。
5. 准备 Azure 订阅以接收来自本地部署的工作负载。
6. 配置站点到站点连接。
7. 使用 Azure 工具将 本地服务器迁移到 Azure。
8. 将您的Citrix 工作负载移至 Azure。

如果您按指定顺序进行迁移，则迁移将更有组织、更有序。通过指定的顺序，您可以将本地部署和云部署组合运行产品、组件和服务，从而最大限度地减少对日常工作负载的中断。

下图显示了我们迁移的环境，其中所有工作负载都在 Azure 上并使用 Citrix Cloud。

受众

我们为以下用户编写了这份文档

• 熟悉 Citrix Virtual Apps and Desktops 网站的管理
• 熟悉 StoreFront 环境的管理
• 熟悉 Azure 的基础知识

如果您了解 Citrix Cloud 基础知识并了解 Citrix Gateway 或 NetScaler Gateway，这也很有帮助。

实验室详情

我们在实验室中使用安装和配置了以下组件的虚拟机运行了迁移工作流程：

• 域控制器、DNS、DHCP、证书服务
• SQL Server 2019 Standard
• Citrix Delivery Controller
• StoreFront 1912
• Citrix Director
• 远程桌面服务 (RDS) 和 Citrix 许可证服务器
• Citrix Workspace Environment Management 服务器
• 文件服务器
• Windows 2016 大师
• Windows 10 大师
• Citrix ADC

Active Directory 结构

整体解决方案的每个组件都需要与 Active Directory (AD) 集成，以便向 Citrix 环境提供身份验证，并通过项目每个部分的 AD 组织单位 (OU) 应用于用户会话的个性化设置。

Citrix 推荐使用类似下图所示的 OU 结构。将 OU 结构与当前结构集成。OU 结构托管 Citrix Cloud 环境的计算机和用户帐户。

Active Directory 准备

对于我们的实验室环境，我们定义了以下 GPO：

1. 配置 Citrix Workspace Environment Management 以定义基础结构服务器。
2. 将 Citrix Workspace 应用程序配置为允许 SSO 并在用户桌面上填充应用程序。
3. 配置登录脚本以使用 BGInfo 应用背景。出于演示目的，我们根据迁移项目的阶段应用不同的背景设置。

基本实验室设置到位后，我们已准备好开始迁移。

我们建议您在启动迁移项目之前创建 AD 结构 GPO 并链接将托管 Azure 工作负载的 GPO。设置检查点也很有帮助，这样您就可以验证每个步骤是否成功完成。

设置基本的 Citrix Cloud 环境

如果您已经在使用 Citrix DaaS，则可以跳至 Workspace Environment Management 服务部分。

我们通过三个步骤设置 Citrix Cloud 环境：

步骤 1：登录

步骤 2：在两个 VMware ESX 虚拟机上部署 Citrix Cloud Connector

步骤 3：重命名资源位置

步骤 1：登录

确保您 订阅了有效的 Citrix DaaS。

要继续，您需要访问 Citrix DaaS。如果您没有访问权限，请联系 Citrix 代表。

步骤 2：Cloud Connector 安装

Citrix Cloud Connector 允许您配置本地部署和 Citrix Cloud 之间的安全通信。要确保 Citrix Cloud Connector 的设置符合规范，请查看 系统要求。您需要两个 VMware ESX 虚拟机来托管两个 Citrix Cloud Connector。

您可以以 交互方式 或使用 命令行安装 Cloud Connector 软件。

步骤 3：重命名资源位置

字段注释：

当您有多个资源位置时，最佳做法是为每个资源位置设置不同的名称。这可以帮助您更轻松地识别它。

1. 选择您的资源位置，单击 … 然后选择 重命名。

   

2. 为资源位置指定一个新名称，例如 本地，然后单击“保存”。

   

检查点：Citrix Cloud Connector

成功部署并运行 Cloud Connector 后，它们将在左侧带有绿色条形列出。

器如果状态不是预期的状态，请使用 Citrix Cloud 服务连接测试工具了解更多信息。

迁移到 Citrix DaaS

如果您已经在使用 Citrix DaaS，则可以跳至 Workspace Environment Management 服务部分。

如果您在本地使用 Citrix Virtual Apps and Desktops，则可以使用本节中的过程作为迁移到 Citrix DaaS 的指南。

对于 MCS 配置方法， MCS 迁移 部分提供了详细的迁移步骤。

有关 PVS 置备方法的信息，请转到 PVS 迁移。

下图显示了我们迁移到 Citrix DaaS 之后在 Azure 上的云环境。

MCS 迁移

第 1 步：准备

要使用自动配置工具成功迁移，对于本地 MCS 配置的目录，您必须复制主机、计算机目录和交付组的本地配置。迁移工具仅为 MCS 部署创建和分配应用程序和策略。

在此迁移阶段，我们建议您仅为每个计算机目录创建几个虚拟机。只有几个虚拟机允许您验证计算机目录的创建，然后允许您创建交付组并运行 Azure 迁移工具。

由于目标是将 Citrix 工作负载迁移到 Azure，因此无需在本地使用 Citrix Virtual Apps 程序和桌面创建所有虚拟机。

使用您的本地主映像创建 Citrix DaaS 计算机目录和交付组。

重要：

要成功运行迁移工具，在 Citrix DaaS 中创建的交付组必须与现有本地交付组具有相同的名称。

建立主机连接

主机连接是您建立网络和存储（资源）用于连接的地方。有关 连接的详细信息，请参阅创建和管理 连接。

创建计算机目录

使用计算机目录将计算机集合作为单个实体进行管理。有关详细信息，请参阅创建计算机目录。计算机目录是创建交付组的先决条件。运行 Azure 迁移工具时，该工具将移交所有设置并创建所需的所有 VM。要确保交付组具有占位符，请在此步骤中创建包含最少数量虚拟机的计算机目录。通常，两个虚拟机足以满足此要求。

创建交付组

使用交付组控制对计算机、应用程序和桌面的访问和交付。有关详细信息，请参阅创建交付组。创建与现有本地交付组名称相同的交付组。

步骤 2：迁移

我们使用 Citrix 开发的工具，即自动配置工具，将 Citrix Virtual Apps and Desktops 从本地迁移到 Citrix DaaS。您可以从 Citrix 下载自动配置工具 。该工具的文档可在Tech Zone 的“自动配置”中找到。

由于我们的本地实验室正在使用 MCS，因此我们只迁移以下内容：

• 应用程序
• Citrix 策略

导出本地站点配置

注意：

由于我们使用的是 MCS 并且只能导入应用程序和组策略，因此我们在这里使用两个选项： -GroupPolicies 和 -Applications 以仅导出所需的信息。

必备条件

我们在交付控制器上运行自动配置工具，我们需要在该服务器上安装 .NET Framework 4.7.2 或更高版本。

可以从以下网址下载 .NET Framework 4.7.2： https://dotnet.microsoft.com/download/dotnet-framework/net472。

在 Delivery Controller 上安装 AutoConfig_PowerShell_x64.msi。安装该工具会创建一个名为 Auto Config 的桌面图标，该图标将启动 PowerShell 命令提示符。您可以在 PowerShell 命令提示符下运行云自动配置 cmdlet。

导出应用

1. 单击自动配置图标。

   

2. 运行以下命令： Export-CvadAcToFile –Applications $true。

   

导出策略

1. 运行以下命令： Export-CvadAcToFile –GroupPolicies $true。

   

2. 确保将结果报告为 True。

将设置导入 Citrix Cloud

您编辑的所有文件都位于运行 PowerShell 命令的文件夹中。运行导出命令时， 自动配置 工具会创建文件。

必备条件

1. 使用 Customer ID、Client ID 和 Secret 编辑并填充 CustomerInfo.yml 文件。

   

2. 连接到 Citrix Cloud 并转至 身份和访问管理。

   

3. 单击 API 访问。

   

4. 记下您的 客户 ID。

   

5. 提供名称，然后单击 创建客户端。

   

6. 复制 ID。

   

7. 复制秘密

   

8. 将信息粘贴到文档中（无法再次看到信息，因此请确保文档安全）。

   

9. 文件填充后，保存它（在引号之间插入您的信息）。

10. 使用记事本编辑 ZoneMapping.yml。

    

11. 将突出显示的文本替换为云资源位置名称，如以下示例所示：

    

注意：

如果默认云资源位置名称尚未更改，则应为“主要”。

根据标准 YAML 语法，主区域的正确语法是在冒号 : 和第一个引号 " 之间保持空格。名称区分大小写，必须如图所示用引号括起来。

导入应用

1. 在自动配置工具中运行以下命令： Import-CvadAcToSite -Applications $true。

   

2. 输入 yes 以验证操作。

   

   生成的输出如下图所示：

   

导入政策

1. 在自动配置工具中运行以下命令： Import-CvadAcToSite -GroupPolicies $true。

   

2. 输入 yes 以验证操作。

   

   生成的输出如下图所示：

   

3. 确保结果为 T rue。

有关每个 VDA 重新配置选项的更多详细信息，请参阅 VDA 注册中的 Citrix 产品文档

检查点：使用 MCS 迁移 Citrix DaaS

1. 连接到 Citrix DaaS，转到 应用程序 并确保应用程序已创建。

2. 转至 策略 并确保已创建和分配您的策略。

如果您使用的是Workspace Environment Management，请继续使用 迁移到Workspace Environment Management 服务。

如果您没有使用Workspace Environment Management，则下一步是 配置最终用户访问层。

PVS 迁移

我们使用 Citrix 开发的工具，即自动配置工具，将 Citrix Virtual Apps and Desktops 从本地迁移到 Citrix DaaS。您可以从 Citrix 下载自动配置工具 。

该工具的文档可在Tech Zone 的“自动配置”中找到。

导出本地站点配置

必备条件

我们在交付控制器上运行自动配置工具，我们需要在该服务器上安装 .NET Framework 4.7.2 或更高版本。

可以从以下网址下载 .NET Framework 4.7.2： https://dotnet.microsoft.com/download/dotnet-framework/net472。

在 Delivery Controller 上安装 AutoConfig_PowerShell_x64.msi。安装该工具会创建一个名为 Auto Config 的桌面图标，该图标将启动 PowerShell 命令提示符。您可以在 PowerShell 命令提示符下运行云自动配置 cmdlet。

导出设置

1. 单击自动配置图标。

   

2. 运行以下命令： Export-CvadAcToFile。此命令与运行 Export-CvadAcToFile -All $True 命令相同。

   

3. 确保将结果报告为 True。

将设置导入 Citrix Cloud

必备条件

1. 使用 Customer ID、Client ID 和 Secret 编辑并填充 CustomerInfo.yml 文件。

   

2. 连接到 Citrix Cloud 并转至 身份和访问管理。

   

3. 单击 API 访问。

   

4. 记下您的 客户 ID。

   

5. 提供名称，然后单击 创建客户端。

   

6. 复制 ID。

   

7. 复制秘密。

   

8. 将信息粘贴到文档中（无法再次看到信息，因此请确保文档安全）。

   

9. 在文件末尾添加以下行： HostConnections: True 以允许托管配置。

   

10. 文件填充后，保存它（在引号之间插入您的信息）。

11. 使用记事本编辑 ZoneMapping.yml。

    

12. 将突出显示的文本替换为 Citrix Cloud 中定义的本地资源位置的名称，如以下示例所示：

    

    注意：

    如果默认云资源位置名称尚未更改，则应为“主要”。

    根据标准 YAML 语法，主区域的正确语法是在冒号 : 和第一个引号 " 之间保持空格。名称区分大小写，必须如图所示用引号括起来。

13. 使用记事本编辑 CvadAcSecurity.yml。

    

14. 使用您的凭据填写文件并保存它。用户名的正确格式是 domain\username。

导入设置

1. 在自动配置工具中运行以下命令： Import-CvadAcToSite -All $true。

   

2. 输入 yes 以验证操作。

   

生成的输出如下图所示：

有关 VDA 注册选项的更多详细信息，请参阅 VDA 注册中的 Citrix 产品文档

检查点：使用 PVS 的 Citrix Virtual Apps 程序和桌面服务

1. 连接到 Citrix DaaS，转到计算机目录并确保已创建计算机目录并分配计算机。

2. 转到 交付组 并确保已创建交付组。

3. 确保您的虚拟机已在 Citrix Cloud Studio 控制台中注册。

4. 转到应用程序并确保已创建应用程序。

5. 转至 策略 并确保已创建和分配您的策略。

如果您使用的是Workspace Environment Management，请继续使用 迁移到Workspace Environment Management 服务。如果您没有使用Workspace Environment Management，则下一步是 配置最终用户访问层。

迁移到 Workspace Environment Management 服务

仅当您在本地使用 Workspace Environment Management 并希望迁移到 Workspace Environment Management 服务时，此步骤才适用。如果这不适用于您，请跳至下一部分 Azure 上的 Citrix 工作负载。

步骤 1：满足系统要求

该工具包支持从 Workspace Environment Management 4.7 及更高版本的迁移。要从早期版本迁移，请将 Workspace Environment Management 4.x 升级到 Workspace Environment Management 4.7 或更高版本，然后将数据库迁移到 Workspace Environment Management 服务。

有关迁移到Workspace Environment Management 服务的详细信息，请参阅 迁移。

下图显示了包含本地资源和 Azure 资源的环境，现在将 Workspace Environment Management 服务添加到我们的云环境中。

字段注释：

要验证我们的 VDA 是否从本地切换到云端，一个简单的技巧是创建仅在 Workspace Environment Management 服务中配置的设置。

步骤 2：切换到服务代理模式

使用代理切换功能从本地切换到服务代理模式。有关代理交换机的信息，请参阅代理交换机。

注意：

代理切换功能可在 Workspace Environment Management 1909 及更高版本中使用。对于早期版本，在使用代理交换机之前，必须重新安装代理或将其升级到 1909 或更高版本。

或者，您可以从服务的下载选项卡下载代理，然后手动重新安装代理。

1. 本地连接到 Workspace Environment Management 控制台。

   

2. 在 高级设置中，单击 代理交换机 选项卡。

   

3. 选中 切换到服务代理复选框，提供 Cloud Connector 服务器，然后单击 应用。

4. 重新启动 VDA 以应用新设置。

检查点：Workspace Environment Management 服务迁移 作为确认我们的 VDA 是否已从本地切换到云的验证步骤，我们添加了一个应用程序记事本，该应用程序是 Workspace Environment Management 服务中唯一可用的。我们使用以下步骤确认交换机。

1. 打开 Win 10 + Citrix DaaS 桌面。

2. 确保使用 Workspace Environment Management 服务（在我们的示例中为记事本）配置的新应用程序已填充在用户的桌面上。

配置最终用户访问层

您有两种配置最终用户访问层的选择：

• 如果您需要特定的 StoreFront 功能，请继续将 StoreFront 与 Citrix Gateway 结合使用
• 迁移到 Citrix Workspace 和 Citrix Gateway 服务

StoreFront 与 Citrix Gateway

在本节中，我们将本地 StoreFront 和 Citrix Gateway 配置为与 Citrix DaaS 集成。为了支持多个 StoreFront 站点，我们使用多站点聚合。

StoreFront

1. 将 Cloud Connector 添加为每个已配置的商店中的交付控制器。

   

2. 通过将 Cloud Connector 添加为 Citrix Gateway 配置中的安全票证颁发机构 (STA) 来添加交付控制器配置。

   

3. 汇总资源。要了解有关多站点聚合的更多信息， 设计 StoreFront 多站点聚合 是一个有用的资源。

4. 将用户映射到控制器。

Citrix Gateway

将 Citrix Cloud Connector 作为 STA 添加到 Citrix Gateway 配置中。

检查点：STA

确保所有 STA 服务器的状态如下图所示。

现在 STA 服务器已启动并配置了 StoreFront。

检查点：使用本地访问层迁移 Citrix DaaS

1. 确保在 Citrix Cloud 中注册了 VDA。Citrix 产品文档提供了对 VDA 注册的更深入的了解。

2. 连接到 Citrix Gateway。

3. 启动已发布的资源。

迁移到 Citrix Workspace 和 Citrix Gateway 服务

在本节中，我们迁移到 Citrix Gateway 服务和 Citrix Workspace，如下图所示。

注意：

评估 Citrix Gateway 服务和 Citrix Workspace 时，请确保所需的自定义和配置可用。

配置

1. 连接到 Citrix Cloud。

2. 单击 主页 > 工作区配置。

   

3. 编辑 Workspace URL 并提供符合您要求的名称。单击保存。

   

4. 单击身份验证。

   

5. 提供支持的身份验证方法。选择所需的一个，然后单击 自定义。

   

6. 您可以使用两个徽标进行自定义。一个用于身份验证页面，另一个用于 Workspace 存储。

   

7. 如有必要，您可以更改颜色。

   

8. 单击保存。

   

9. 单击 Service Integrations（服务集成）。

   

10. 启用 Virtual Apps and Desktops。

    

11. 单击确认。

    

12. 单击“访问”。

    

13. 在资源位置右侧，单击 3 个点 … 然后选择 配置连接。

    

14. 选择 网关服务 ，然后单击 保存。

检查点：Citrix Workspace 和 Citrix Gateway 服务迁移

1. 确保在 Citrix Cloud 中注册了 VDA。Citrix 产品文档提供了对 VDA 注册的更深入的了解。

2. 连接到您的 Citrix Workspace URL。

3. 启动已发布的资源。

准备 Azure 订阅

将工作负载迁移到 Azure 的第一步是设置 Azure 环境。如果您不熟悉 Azure，或者您的环境中有一些与我们的实验室设置不同的组件，Microsoft 会提供许多有用的资源，比如 Azure 新手？请按照以下简单步骤开始使用， 并参阅 Azure 迁移文档。

要详细了解如何在 Azure 上架构 Citrix Virtual Apps and Desktops，请参阅 Azure 上的 Citrix DaaS。

我们分五个基本步骤准备了 Azure 环境：

步骤 1：选择 Azure 订阅模式

步骤 2：选择 Azure 区域

步骤 3：创建资源组

步骤 4：创建虚拟网络

步骤 5：在 Azure 中部署服务器，在我们的例子中，该服务器充当域控制器。您可以部署任何方便的服务器类型，也可以完全跳过此步骤。

当我们的 Azure 订阅设置完毕并为下一步做好准备后，我们的环境与下图中的环境类似。资源和工作负载都在本地，我们在 Azure 中有资源组、虚拟网络和服务器。

步骤 1：选择 Azure 订阅模式

设置您的 Azure 订阅。

选择订阅模式是一项复杂的决策，涉及了解 Citrix 部署内外 Azure 占用空间的增长。即使 Citrix 部署很小，您也可能仍然有大量其他资源对 Azure API 进行大量读取/写入。这种繁重的读/写活动可能会对 Citrix 环境产生负面影响。相反的情况也是如此，其中许多 Citrix 资源可能会消耗过多的可用 API 调用，从而降低了订阅中其他资源的可用性。有关 Azure 订阅限制和配额的信息，请参 阅 Azure 订阅和服务限制、配额和约束。

步骤 2：选择 Azure 区域

Azure 区域是在延迟定义的外围内部署的一组数据中心，并通过专用的区域低延迟网络进行连接。Azure 为客户提供了在需要的地方部署应用程序的灵活性。Azure 通常在全球 60 个地区和 149 个国家/地区推出。 Microsoft 在 https://azure.microsoft.com/en-us/global-infrastructure/regions/ 中提供了详细信息。

步骤 3：创建资源组

Azure 中的资源组是逻辑组中的资产集合，用于轻松甚至自动配置、监视和访问控制，并更有效地管理其成本。在 Azure 中使用资源组的好处是，您可以对属于应用程序的相关资源进行分组。由于应用程序的资源共享从创建到使用，最后是取消配置的统一生命周期，因此可以一起管理它们以提高效率。

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

如果您需要设置资源组的指导，Microsoft 将在 什么是 Azure Resource Manager中提供详细信息。

在初始创建过程中，可以将一个或多个资源组应用于计算机目录。这些资源组不能在计算机目录之间共享。每个 Azure 资源组的虚拟机、托管磁盘、快照和映像数量都没有限制。已取消每个 Azure 资源组每 800 个托管磁盘 240 个虚拟机的限制。

资源组在创建时与计算机目录关联，以后无法添加或更改。要将资源组添加到计算机目录，必须删除并重新创建计算机目录。

步骤 4：在 Azure 中创建虚拟网络

需要虚拟网络才能在环境中的资源之间实现安全通信。有关在 Azure 中创建虚拟网络的详细信息，请参阅 快速入门：使用 Azure 门户创建虚拟网络。有关配置虚拟网络的帮助，请参阅 什么是 Azure 虚拟网络。

步骤 5：在 Azure 中部署服务器（可选）

在建立资源组和虚拟网络之后，我们已准备好在 Azure 中部署服务器。我们使用此服务器作为域控制器。它可以帮助我们在建立站点到站点连接后验证 AD 复制。如果需要有关如何设置虚拟机的更多详细信息，请参阅 快速入门：在 Azure 门户中创建 Windows 虚拟机。Microsoft 还在 Azure 中的虚拟机大小中为您的工作负载选择合适大小的 VM 提供了有用的指导。

步骤 5 是可选的。我们在 Azure 中部署了服务器，以更好地表示典型部署。

既然我们已经创建了资源组和虚拟网络，并部署了服务器，下一步是配置本地环境和 Azure 环境之间的连接。

配置站点到站点连接

要将本地环境连接到 Azure，您有多种选择：

• 站点到站点 VPN 详细信息可在 Azure 门户中创建站点到站点连接中找到。

• 快速路线快速路线 分步指南位于 快速路线文档中。

出于演示目的，我们使用了站点到站点 VPN。

下图显示了如何将 Azure 环境设置为与本地环境进行通信。

检查点：站点连接

实施连接后，检查点是与来自本地环境的 Azure 资源进行通信，反之亦然。

在我们的例子中，我们使用了两种方法：

选项 1：在每个位置的资源之间使用 ping 命令进行测试。

选项 2：将 Azure 中部署的服务器加入我们的本地 AD 域。如果省略了步骤 5，则可以跳过此选项。

既然我们已配置并验证了站点到站点的连接，下一步是将本地工作负载迁移到 Azure。

将本地工作负载迁移到 Azure

在典型的 Citrix 客户部署中，有多个组件可以迁移。组件类型和迁移计划可能因客户而异。

要更好地了解如何进行迁移，请参阅 适用于 Azure 的 Microsoft 云采用框架。

在本节中，我们将介绍与 Citrix 密切相关的组件的迁移，例如用于配置文件和文件夹重定向的文件服务器以及用于置备的主映像。出于本文档的目的，我们将迁移限制到实验室环境中的组件。但是，对于生产环境，您可以选择将更多的基础架构迁移到 Azure。

文件服务器技术

Azure 提供了多种文件服务器技术，可用于存储 Citrix 用户数据、漫游配置文件信息或作为 Citrix App Layering 网络文件共享的目标。Azure 选项包括：

• 使用 Azure 文件的独立文件服务器

• 使用 存储副本的文件服务器

• 使用 直接存储空间 (S2D) 的横向扩展文件服务器 (SOFS)

• 分布式文件系统复制 (DFS-R)

• 来自 Azure 市场的第三方存储设备（例如 NetApp 和其他设备）

选择最符合业务需求的文件服务器技术。Azure 存储简介 提供了存储类型和相应使用案例的列表，可帮助您确定哪种存储类型最适合您的情况。

基础设施成本管

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

尽管 Azure 预留实例要求对计算容量做出预付承诺，但它们也提供了随时交换或取消预留实例的灵活性。预留仅涵盖虚拟机计算成本。它不会降低任何额外的软件、网络或存储费用。这对 Citrix 基础架构和使用案例（在非工作时间）所需的最低容量非常有用。

Azure 虚拟机实例类型

每个 Citrix 组件在 Azure 中使用关联的虚拟机类型。每个可用的 VM 系列都映射到特定类别的工作负载（通用工作负载、计算优化等），各种大小控制分配给 VM 的资源（CPU、内存、IOPS、网络等）。 虚拟机系列提供了该系列 及其功能的详细说明。

大多数 Citrix 部署使用 D 系列和 F 系列实例类型。D 系列通常用于 Citrix 基础架构组件，有时用于用户工作负载，当用户需要超出 F 系列实例类型中的内存时，用于用户工作负载。F 系列实例类型是现场用户工作负载中最常见的，因为它们的处理器速度更快，从而带来了响应能力的感觉。

为什么选择 D 系列或 F 系列？从 Citrix 的角度来看，大多数基础架构组件（云连接器、StoreFront、NetScaler 等）都使用 CPU 来运行核心进程。这些虚拟机类型的 CPU 与内存之比均衡，托管在统一硬件上（不同于 A 系列），以实现更一致的性能并支持高级存储。当然，您可以也应该调整实例类型以满足您的需求和预算。

基础架构中组件的大小和数量始终取决于您的要求、规模和工作负载。但是，使用 Azure，我们可以按需动态扩展。对于注重成本的人来说，从小规模开始并向上扩展是最佳方法。更改大小时，Azure VM 需要重新启动，因此只能在计划的维护时段内并在既定的更改控制策略下计划这些事件。Citrix 在 Azure 上交付 Citrix Virtual Apps and Desktops 服务的可扩展性和经济性中提供了更详细的分析

存储

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

Azure 磁盘旨在提供企业级持久性。您可以从创建磁盘时存在的两个存储性能层中进行选择：高级 SSD 磁盘和标准 HDD 存储。磁盘可能是托管的，也可以是非托管磁盘。托管磁盘是默认磁盘，不受存储帐户限制（如非托管磁盘）的约束。

Microsoft 推荐托管磁盘而不是非托管磁盘。仅在例外情况下才应考虑非托管磁盘。考虑一下，标准存储（HDD 和 SSD）包括交易成本（存储 I/O），但每个磁盘的成本较低。高级存储没有事务成本，但每个磁盘的成本较高，并提供了更好的用户体验。

磁盘仅在使用可用性集时提供 SLA。Citrix MCS 不支持可用性集。在 Azure 上为 Citrix Cloud Connector、Citrix ADC 或 StoreFront 创建虚拟机时，请使用可用性集。

Azure 迁移服务概述

Azure Migrate 提供了一组用于评估和迁移到 Azure 本地服务器、基础架构、应用程序和数据的工具。有关详细信息，请参阅 关于 Azure 迁移。我们使用 Azure Migrate 迁移我们的文件服务器和主映像。

下图显示了迁移到 Azure 时资源的位置。

我们建议采用三个步骤的过程：

步骤 1：发现

第 2 步：评估

步骤 3：迁移

注意：

对于 PVS 用户，在迁移到 Azure 之前，需要执行特定步骤来准备环境。请按照下一节中的这些步骤操作。MCS 用户可以直接访问 发现。

PVS 专用图像准备的先决条件

对于每个 PVS 映像，必须从预配中删除虚拟机，并临时配置它，使其仅托管在 VMware vSphere 上。您使用反向映像来完成此操作。反向映像有多种方法。 CTX202159：如何在适用于 Windows 的 Provisioning Services 目标设备上执行反向映像及其适用用法中详细介绍了其中之一。

步骤 1：发现

第一步是创建迁移项目并选择要使用的工具。您需要为发现过程设置设备。有关更多详细信息，请参阅 发现计算机应用程序、角色和功能。

Microsoft 提供了两种设置设备的方法：

• OVA 模板（可下载的文件）

• 脚本

Azure Migrate 设备连接到 vCenter Server 以使用无代理迁移来发现和迁移虚拟机。

部署设备并提供凭据后，设备将开始持续发现虚拟机元数据和性能数据，同时发现应用程序、功能和角色。应用发现的持续时间取决于您拥有的虚拟机数量。应用程序发现 500 个虚拟机通常需要一个小时。

第 2 步：评估

根据发现结果，您可以创建 vCenter 上所有本地资源的评估。

对于评估（Microsoft 推荐），您有多种选择。我们对 Citrix 工作负载最感兴趣的两个是：

• Azure 迁移：服务器评估

• Movere

我们在此项目中使用 Azure 迁移：服务器评估。

迁移工具提供了环境的概述，详细信息如下：

• 名称
• IP 地址
• 已安装应用
• 依赖项
• 核心
• 内存
• 磁盘
• 存储
• 操作系统

在评估配置期间，您可以访问评估属性，这些属性允许您：

• 选择目标位置
• 选择存储类型
• 选择是否要基于预留实例进行评估
• 选择尺码标准
• 选择绩效历史
• 选择百分位数利用率
• 选择虚拟机系列
• 选择舒适因素
• 选择定价详情

要发现依赖关系，您需要在虚拟机上部署软件。请参见 分析计算机依赖关系（无代理）。

依赖项有助于了解何时迁移应用程序或数据库服务器。了解依赖关系可让您准确确定需要迁移哪些服务器，以确保服务器之间的持久安全连接。

为了便于迁移，我们创建了一个仅包含我们打算迁移的虚拟机的组。

步骤 3：迁移

对于服务器迁移，Microsoft 为基于代理和无代理的方法提供了选项。我们这里的重点是无代理方法，如 将 VMware 虚拟机迁移到 Azure（无代理）中所述。要确定适合您业务的最佳方法，请参阅 选择 VMware 迁移选项。

迁移过程始于将本地虚拟机初始复制到 Azure。

该过程的持续时间取决于与虚拟机关联的磁盘的大小和带宽。持续时间还取决于

• 并发迁移的数量
• vCenter 上的带宽
• 存储的可用性（对于无代理方法）
• 您的网络带宽

在复制过程中，您需要选择：

• VMware vSphere
• 要使用的设备
• 选择要迁移的虚拟机（导入评估，选择组）
• 选择目标设置
• 选择计算
• 选择磁盘

当增量复制开始时，在初始复制之后，您可以在 运行到 Azure 的完全迁移之前运行测试 迁移。

我们强烈建议您在迁移每台计算机之前至少为其运行一次测试迁移。

• 运行测试迁移会检查迁移是否按预期运行，而不会影响本地计算机，后者仍在运行并继续复制。

• 测试迁移通过使用复制数据创建 Azure VM（通常迁移到 Azure 订阅中的非生产 VNet）来模拟迁移。

• 在完全迁移之前，您可以使用复制的测试 Azure VM 验证迁移、执行应用程序测试以及解决任何问题。

完成迁移

按照 Microsoft 的指导完成迁移 和 迁移后最佳实践。

1. 迁移完成后，右键单击并选择 虚拟机 > 停止复制。此命令停止本地计算机的复制，并清理 VM 的复制状态信息。

2. 在迁移的计算机上安装 Azure VM Windows 或 Linux 代理。

3. 执行任何迁移后的应用程序调整，例如更新数据库连接字符串和 Web 服务器配置。

4. 在 Azure 中运行的迁移应用程序上执行最终应用程序和迁移接受测试。

5. 切断向迁移的 Azure 虚拟机实例的流量。

6. 从本地虚拟机清单中删除本地虚拟机。

7. 从本地备份中删除本地虚拟机。

8. 更新任何内部文档以显示 Azure 虚拟机的新位置和 IP 地址。

迁移后的最佳实践

• 为了提高弹性：

  • 使用 Azure 备份服务备份 Azure 虚拟机，确保数据安全。有关详细信息，请参阅在 Azure 中备份虚拟机。
  • 使用“站点恢复”将 Azure 虚拟机复制到辅助区域，保持工作负载正常运行并持续可用。有关详细信息，请参阅为 Azure 虚拟机设置灾难恢复。

• 为了提高安全性：

  • 使用Azure 安全中心锁定和限制入站流量访问-即时管理。
  • 使用网络安全组将网络流量限制到管理端点。
  • 部署Azure 磁盘加密以帮助保护磁盘，并保护数据免遭盗窃和未经授权的访问。
  • 阅读有关保护 IaaS 资源的更多信息，并访问Azure 安全中心。

要进行监视和管理，请考虑使用 Citrix Application Delivery Management 服务。

考虑部署Azure 成本管理来监控资源使用情况和支出。

检查点：Azure 迁移

1. 在迁移后验证分配给 Azure 上文件服务器的 IP 地址。

2. 确保 DNS 服务器上的 IP 地址已更新。

3. 使用新用户帐户连接到 Citrix Gateway。

4. 打开 Citrix DaaS 桌面。

5. 关闭会话并确保已在 Azure 的文件服务器上创建用户的配置文件。

将 Citrix 工作负载移动到 Azure

接下来，我们将 Citrix 工作负载移动到 Azure。

下图显示了已迁移的 Azure 和 Citrix Cloud 组件以及剩余的本地环境。

步骤 1：先决条件

1. 在 Azure 上部署两个Cloud Connector。

   

2. 在 Citrix Cloud 中创建资源位置。

   

3. 在服务器上部署 Cloud Connector 软件并将其附加到新的资源位置。

   

步骤 2：创建 Citrix 工作负载

1. 创建基本配置
   1. 托管
   2. 计算机目录
   3. 交付组
   4. 发布应用
   5. 绑定 Citrix 策略

步骤 3：配置最终用户访问层

注意：

如果您未使用 Citrix Workspace 和 Citrix Gateway 服务，请按照以下步骤操作。

1. 连接到本地 StoreFront 服务器，将 Azure Cloud Connector添加为每个应用商店的交付控制器。

   

2. 为内部存储配置用户映射和 多站点聚合 （在过渡步骤中）。

   

3. 为外部存储配置用户映射和多站点聚合。

   

4. 将 Azure 托管的Cloud Connector作为 STA 添加到 StoreFront 的 Citrix Gateway 配置中。

   

5. 在 Citrix ADC 上的 Citrix Gateway 虚拟服务器配置中添加 Azure 托管的Cloud Connector作为 STA。

   

6. 确保所有 STAS 都已 启动。

检查点：Citrix 工作负载

1. 连接到 Citrix Gateway。

2. 打开 Azure 托管的 Citrix Virtual Apps 程序和桌面服务已发布的桌面。

3. 确保桌面的名称是您在 Azure 上预配的桌面名称。

4. 启动应用程序以确保它们启动。记下应用程序的性能。如果您的应用性能不佳，您可能需要调整 Azure 计算机的大小。