设计决策：使用 Azure 文件的 Citrix Profile Management
简介
本文介绍了使用 Citrix 用户配置文件管理器管理作为后端存储位置的 Azure 文件上的用户配置文件的指南和最佳实践。本文的主要目标是为您提供必要的信息，以确定在 Azure 文件中部署用户配置文件管理器的最佳方法。
本文讨论了 Citrix 和 Microsoft 组件、描述测试方法并报告测试结果。本文还对关键部署决策的调查结果和指导进行了分析。最后，还提供了有关保护、保护和迁移用户配置文件数据的其他信息。
Azure 文件
Azure Files 是一种安全、公开托管的服务器消息块 (SMB) 或网络文件系统 (NFS) 文件共享，具有低延迟访问。Azure 文件支持 Active Directory 集成和 NTFS 文件级权限，可从 Windows、Mac 和 Linux 客户端访问。
Azure 文件可用于各种企业目的，包括
-
文件服务器。Azure 文件可以直接从世界各地的所有流行操作系统挂载。Azure 文件也可以在混合场景中部署，在这种情况下，可以通过 Azure 文件同步将数据复制到本地 Windows 服务器。
-
应用程序迁移。将用户应用程序及其数据同时移动到云中。或者，您可以先移动用户数据，然后在混合配置中运行，直到应用程序可以移动到云中。
-
简化云开发。使用 Azure 文件存储共享应用程序设置、诊断日志、指标或开发人员实用程序。
-
容器化。使用 Azure 文件持久存储容器或作为共享存储文件系统。
Azure Files 拥有支持共享访问、完全托管、弹性的文件共享，是为 Citrix 用户存储用户配置文件数据的绝佳场所。Azure 文件使用 SMB 3.0，因此传输的所有数据在传输过程中都受加密保护。
性能等级
Azure 文件有四种不同的性能级别，具有不同的成本和性能指标。对事务优化和高级两个层进行了评估和推荐，用于存储用户配置文件数据
事务 优化 （以前称为标准）性能在单个文件共享中提供高达 100 TB 的存储空间，最大吞吐量为 300 MiB/ 秒。事务性能级别旨在支持不需要高性能的工作负载。对用户配置文件工作负载使用事务优化选项时，请务必启用“大文件共享”设置。启用了“大文件共享”的事务文件共享支持的最大 IOPS 为 10,000 IOPS。对于 10 TiB 股份和 100 TiB 股份来说，情况也是如此。
未启用“大文件共享”(< 5 TiB) 的事务存储帐户支持多种冗余选项。这些选项包括本地冗余、区域冗余和具有只读和热或冷分层的地理冗余选项。启用对“大型文件共享”的支持时，只有本地冗余存储和区域冗余存储选项可用。
高级 性能根据预配置的文件共享大小，在单个文件共享中提供高达 100 TiB 的存储空间，具有 100,000 IOPS 和吞吐量。高级文件共享的基本入口为 40 MiB/Sec +（0.04 * 预配置 GiB），而基本出口速率为 60 MiB/Sec +（0.06 * 预配置 GiB）。对于 10 TiB 股份，吞吐量相当于 450 MiB/ 秒的入口速率和 675 MiB/ 秒的出口速率。高级性能级别旨在支持 I/O 密集型工作负载，同时提供不到 10 毫秒的延迟。
IOPS 和吞吐量根据文件共享的大小进行预置。请务必预置的大小可以涵盖用户所需的 IOPS 和吞吐量。对于高级文件共享，为每个 GiB 预配置空间分配的基本 IOPS 为 400 + 1 IOPS，最多为 100,000 IOPS。高级股份可以突增至 4000 IOPS 或分配的基本 IOPS 的 3 倍。将为 10 TiB 文件共享分配 10,240 IOPS。对于高级文件共享，拆分模式允许使用分配的 IOPS 的 3 倍。但是，拆分模式要求文件共享以低于分配的 IOPS 运行一段时间才能重新生成。换句话说，您不能一定在突发模式下运行。如果有足够的积分，股票最多可以爆发 30,720 IOPS，持续时间最长为 60 分钟。
两个性能层都是存储用户配置文件数据的可接受选项在性能层之间进行选择主要取决于用户工作负载。我们的目标始终是以最低的成本为最终用户提供所需的性能和数据保护。对于响应时间为最高优先级的用户配置文件，高级文件共享是最佳选择。有关不同层的性能的更多信息，请访问 Microsoft 的存储性能网页。要确定哪个性能级别最佳，首先要监控关键指标。
监视
您可以使用 Azure 监视器查看 Azure 文件共享的关键指标并进行调整。对于存储，请密切监控吞吐量、事务和延迟指标。要启用这些指标，请在 Azure 门户中选择存储帐户，然后从存储帐户刀片中选择指标。我们在测试期间用于监控 Azure 文件性能的关键指标如下：
入口（总和）：此时段内 Azure 文件的入站数据的汇总和（以字节为单位），最小粒度为一分钟。要确定每秒的平均入口吞吐量，您需要将入口数据的总和取一分钟，然后除以 60。要添加此指标，请单击添加指标，然后将范围设置为存储帐户名称。将 命名空间 设置为帐户，然后选择 Ingress 作为 量度 ，选择 Sum 作为 聚合 类型。
出口（总和）：此时间段内来自 Azure 文件的出站数据的总和（以字节为单位），最小粒度为 1 分钟。要确定每秒平均出口吞吐量，您需要将出口数据的总和取一分钟，然后除以 60。要添加此指标，请单击添加指标，然后将范围设置为存储帐户名称。将 命名空间 设置为帐户，然后选择出口作为 指标 ，选择总和作为 聚合 类型。
事务（总和）：在该时段内向 Azure 文件发出的成功和失败的请求数，最小粒度为一分钟。此指标大致类似于每秒输入/输出操作数 (IOPS)。要确定一分钟内的平均 IOPS，您需要获取该分钟的事务总和，然后除以 60。要添加此指标，请单击 添加指标 ，然后将范围设置为存储帐户名称。将 命名空间 设置为帐户，然后选择事务作为 指标 ，选择总和作为 聚合 类型。
使用限制的事务成功（总和）：由于第一次尝试时预配的限制而失败但在重试后成功的请求的汇总数。此指标是响应类型的 API 过滤器，仅对预配资源的高级层有效。如果与事务总和相比，此数字很大，请增加文件共享大小。要添加此筛选器，您必须首先添加事务量度。然后单击 添加过滤器，选择 响应类型 属性， 运算符 =，然后在 值 字段中选择其中一个过滤器。除非您看到受限的事务，否则此过滤器不会作为选择显示。对于高级共享，您还可以查看特定的响应类型（SuccessWithWthShareopsCrottling、SuccessWithWthShareegressCrottling、SuccessWithWthShareingressCrottling），以确定 IOPS 或吞吐量是否受到限制。有关指标维度的更多信息，请访问 Microsoft 网站。
成功服务器延迟 (Avg)：Azure 文件完成请求所需的平均时间。此值不包含任何网络延迟。如果此值增加，则 Azure Files 基础架构将以最大容量运行并落后。要添加此指标，请单击添加指标，然后将范围设置为存储帐户名称。将 命名空间 设置为帐户，然后选择成功服务器延迟作为 指标 ，选择 Avg 作为 聚合。
成功 E2E 延迟 (Avg)：使用 Azure 文件成功完成事务所需的平均端到端延迟。此值包括客户端和 Azure 文件之间的网络延迟。如果与成功服务器延迟值相比，此数字正在增加，请调查网络。要添加此指标，请单击添加指标，然后将范围设置为存储帐户名称。将 命名空间 设置为帐户，然后选择成功 E2E 延迟作为 指标 ，选择 Avg 作为 聚合。
Citrix Profile Management
Citrix Profile Management (CPM) 的使用大大增强了测试期间的最终用户体验。Citrix Profile Management旨在消除配置文件膨胀并显著加快登录时间，同时减少配置文件损坏。Citrix Profile Management是 Citrix Virtual Apps and Desktops 服务的功能。
主要功能
将 Azure 文件用于后端存储时，CPM 的主要功能可提供出色的最终用户体验如下：
配置文件流：只有用户在登录后访问文件时，才会将配置文件中包含的文件和文件夹从用户存储提取到本地计算机。通过减少用户登录时复制到本地配置文件的数据量，配置文件流显著缩短了登录时间。默认情况下，此设置处于启用状态，可减少离开 Azure 文件的事务和导出数据量，从而降低成本并缩短登录时间。
活动回写：在注销之前，可以在会话中将修改的文件和文件夹同步到用户存储中。通常，这些会话中写入大约每 5 分钟发生一次。启用此设置可为 Azure Files 提供更一致的写入流量流，而不是在注销时执行所有写入操作。这种频繁的回写解决了当用户同时从多台设备访问其个人资料时，“最后一次写入者赢”的问题。
大文件处理：为了提高登录性能和处理大型文件，将创建一个符号链接，而不是复制此列表中的文件。您必须配置存储文件的路径，但可以使用通配符。在使用事务级别时，强烈建议使用此设置，并建议将此设置用于高级套餐。
Profile Management 配置
对于测试，每台 Citrix 主机都安装了多会话操作系统虚拟交付代理 (VDA) 2006。安装过程中，在其他组件屏幕上，Citrix User Profile Manager 和 Citrix User Profile Manager WMI 插件均已启用。
配置了以下配置文件管理的 GPO 设置，并将 GPO 分配给用于测试的所有 Citrix 主机。
| GPO 设置 | 值 |
|---|---|
| 主动回写 | 已启用 |
| 主动回写注册表 | 已启用 |
| 启用 Profile Management | 已启用 |
| 用户存储路径 | |
| 客户体验改善计划 | 已禁用 |
| 启用默认排除列表 — 目录 | 已启用 |
| 注销时删除本地缓存的配置文件 | 已启用 |
| 本地配置文件冲突处理 | 删除本地配置文件 |
| 启用默认排除列表 — 注册表 | 已启用 |
| 大文件处理 — 作为符号链接创建的文件 | OSTFolder\.ost PSTFolder\.pst |
监视
监控性能可以通过 Citrix Director 完成。要注意性能的关键指标是配置文件加载时间。配置文件加载时间提供了用户配置文件加载到 Citrix 会话所需的秒数。配置文件加载时间包括从配置文件存储向下复制用户配置文件所需的时间，在本例中是从 Azure 文件中复制用户配置文件所需的时用户配置文件加载时间对用户体验有重大影响。配置文件加载时间超过 30 秒，通常会导致用户体验不佳。配置文件加载时间可通过 Citrix Director 获取。从 Citrix Cloud Virtual Apps and Desktops 服务中，选择 监控 » 趋势 » 登录性能 ，如以下屏幕截图所示：
通过将鼠标悬停在图表下表中监视或查看的时间段上，即可获得配置文件加载时间。
测试方法
主要目标是评估负载下的 Azure 文件共享，并针对特定工作负载确定事务优化和高级层在 Citrix 主机上配置的 CPM 的执行方式。测试运行期间以下设置保持静态
| 静态配置 | 值 |
|---|---|
| 用户数 | 1000 |
| 文件共享配额大小 | 10TB |
| 文件夹重定向 | 已启用桌面、文档和图片 |
| 大文件处理 | 在启用 CPM 大文件的情况下更新了 4 GB OST 文件 |
| 登录率 | 每小时 1000 个用户，或者每 3.6 秒 1 个用户 |
| 用户资料大小 | 4.7 GB，400 个文件 |
以下测试变量是在各种不同配置的各种测试运行中评估性能之后决定的。
| 变量 | 要测试的价值 |
|---|---|
| Azure 文件层 | 事务优化 |
| Premium | |
| 每小时更新的文件 | 20,000 个文件 |
| 40,000 个文件 | |
| 60,000 个文件 | |
| 80,000 个文件 | |
| 100,000 个文件 |
为了使用少量资源模拟 1000 个用户，我们设计了一个使用自定义 PowerShell 脚本的测试。该脚本随机更新了存储在用户重定向文件夹（87.5％）或用户本地配置文件（12.5％）中的多个文件。单用户运行此脚本时将在会话中更新 20 到 100 个文件（取决于每小时要更新的文件数量）。该脚本还更新了存储在本地配置文件夹中的 4 GB OST 文件。
为了控制启动速率并在会话期间提供随机等待时间，我们在测试框架中使用 LogInvSi。随机等待有助于防止用户同时登录导致的可预测的网络流量峰值，并有助于模拟更好的工作负载。用户将在注销之前登录并访问所需的文件。要从结果中排除注销流量，在任何用户注销之前，所有用户都已登录并访问了文件。这些图表显示了用户登录时测试前一小时的指标。
测试环境设置
对于需要测试的 100,000 个文件，我们构建了一个支持在 60 分钟窗口内登录 1,000 个用户会话的环境。为了避免测试基础架构成为瓶颈，Citrix 主机服务器被故意过大，以便将性能问题移至 Azure Files 共享。
我们在 Azure 美国西部 2 区域配置了两个对等虚拟网络。一个虚拟网络包含 LogInvSi 基础架构，用于管理会话和报告进度。其他虚拟网络包含在标准 FS16_v2 实例上运行的 30 个 Citrix 主机，该实例具有 1 TB 高级 SSD 驱动器。Citrix 服务器托管了需要从 Azure 文件加载和写入用户配置文件的会话。我们启用并配置 Citrix Profile Management以使用 Azure 文件 SMB 共享作为路径存储。
创建了两个 Azure 存储帐户，一个具有事务优化层中小型企业共享，另一个具有高级 SMB 共享。事务层上启用了“大文件共享”设置。两个存储帐户都使用本地冗余存储 (LRS)。默认用户配置文件有 400 个文件，大小从 85 KB 到 5225 KB 不等，外加单个 4 GB 文件用于大文件测试。用户配置文件的总大小约为 4.7 GB。
Citrix Cloud 用于管理计算机目录和交付组。枚举使用了本地 StoreFront 服务器。30 台 Citrix 主机使用 Citrix 多会话操作系统虚拟交付代理 (VDA) 2006 运行 Windows Server 2016。Citrix StoreFront 服务器和 Citrix Cloud Connector 位于 LogInvSi 基础架构的子网中，Citrix 主机驻留在不同的子网中。
测试运行
根据之前确定的变量，运行了以下测试矩阵，并在每次运行时从 Azure 监视器和 Citrix Director 收集性能数据。
| 运行名称 | Azure 文件层 | 文件共享配额 | 文件已更新 |
|---|---|---|---|
| Premium-20K | Premium | 10TB | 20000 |
| Premium-40K | Premium | 10TB | 40000 |
| Premium-60K | Premium | 10TB | 60000 |
| Premium-80K | Premium | 10TB | 80000 |
| Premium-100K | Premium | 10TB | 100000 |
| Transaction-20K | 事务优化 | 10TB | 20000 |
| Transaction-40K | 事务优化 | 10TB | 40000 |
| Transaction-60K | 事务优化 | 10TB | 60000 |
| Transaction-80K | 事务优化 | 10TB | 80000 |
| Transaction-100K | 事务优化 | 10TB | 100000 |
预热测试运行后，每次测试运行都包括以下步骤
-
对于高级套餐，请等待 2 小时以允许突发 IOPS 重新生成
-
更新分配给 Citrix 主机服务器的计算机 GPO 以将 用户的配置文件位置设置为正确的文件共享（事务 或高级）
-
重新启动 Citrix 服务器
-
将 PowerShell 脚本设置为更新正确数量的文件（20、 40、60、80、100）
-
将测试运行配置为在 60 分钟内启动所有 1000 个用户会话
-
启动测试
-
记录开始日期/时间
-
每个会话在注销前至少运行 60 分钟
-
在所有会话注销后，记录停止日期/时间
-
为关键指标收集 Azure 监视器数据
-
为登录性能收集 Citrix Director 数据
测试结果
测试结果按前面讨论的关键指标显示：事务 (IOPS)、吞吐量（出口和入口）、延迟和配置文件加载时间。请注意，这些测试是在 SMB 多渠道发布之前运行的。Azure 文件的 SMB 多渠道与配置文件服务一起使用时可以提高性能。
Transactions（事务数）
事务记录为 Azure 文件指标的一部分。上面的图表显示了在所有测试运行中使用的 IOPS 数量相当一致。无论文件共享类型如何，平均每秒 IOPS 都低于 3300。预计结果一致，因为测试只改变了两种文件共享类型之间接触的文件数量。文件本身对于每个用户配置文件都是一样的。
由于两个文件共享在测试配置中都支持 10,000 IOPS，因此我们的工作负载所需的 IOPS 完全在限制之内。这表明，在 IOPS 成为瓶颈之前，Azure 文件可以支持此工作负载的 3 倍。
吞吐量
吞吐量可作为 Azure 文件指标的一部分提供。以下图表显示了不同层的出口和入口流量。出口流量高于入口流量，因为 Citrix Profile Manager 在登录时扫描完整配置文件，但只更改部分文件。如果配置文件流未作为 Citrix Profile Manager 的一部分启用配置文件流，则整个配置文件将被读取并复制到本地主机。随着运行期间更新的文件数量的增加，出口吞吐量也会增加。这种行为是因为整个文件被传输到本地主机、进行更改并写回共享。
高级股份的吞吐量大大超过 675MiB/秒出口量和450MiB/秒的入口量以内。在吞吐量开始成为问题之前，高级份额能够处理大约 15 倍的工作负载，是我们的测试。
事务文件共享限制较高，为 300 MIB/秒，因此，从理论上讲，事务性文件共享可以在吞吐量成为瓶颈之前处理 5 倍的工作负载。
这些结果正在写入 4 GiB OST 文件，但由于启用了大型文件处理，该文件无法读取到本地主机。对 OST 文件的写入直接在 Azure 文件共享上进行，就像文件夹重定向写入操作一样。
延迟
延迟可作为 Azure 文件指标的一部分提供。下图显示了高级测试和事务优化测试运行中的成功服务器延迟度量。高级层文件共享最好使用较少的大型文件，例如 FSlogiX 和 Citrix Profile Manager VHD 容器等用户配置文件技术。使用容器文件可以提高 Azure 文件的性能，因为打开/读取/写入/关闭文件的请求数量会减少。
关注高级文件共享，我们发现延迟保持相对稳定，约为 4 毫秒。查看事务优化的文件共享，在不同测试运行期间，延迟保持一致。延迟保持在 7-10 毫秒范围内，只有偶尔出现超出该范围的峰值。随着用户稍后登录，这些较长的延迟将转化为更长的配置文件加载时间。这些将在配置文件加载时间部分进一步讨论。
档案加载时间
配置文件加载时间是 Citrix Director 趋势分析的一部分。下表简要概述了基于从 Citrix Director 收集的运行数据的平均配置文件加载时间。
| 跑 | 平均加载时间（秒） |
|---|---|
| Premium-20K | 8.00 |
| Premium-40K | 5.34 |
| Premium-60K | 9.10 |
| Premium-80K | 5.31 |
| Premium-100K | 8.47 |
| Transaction-20K | 15.30 |
| Transaction-40K | 19.12 |
| Transaction-60K | 14.09 |
| Transaction-80K | 18.58 |
| Transaction-100K | 12.09 |
以下图表显示了测试运行期间用户配置文件加载时间在前一分钟的移动平均值。
正如预期的那样，高级级别提供了总体上最佳的加载时间。有趣的是，Premium-80K 跑步的平均加载时间最佳，其次是 Premium-40K。而负载最轻的 Premium-20K 与 Premi-100K 处于中间。Premim-60K 运行的加载时间最差。这些数字显示了性能层内的可变性，尽管它可以在 10 秒内始终提供配置文件加载时间。
事务文件共享似乎很公平，用户的配置文件加载时间平均不到 20 秒，加载时间略有变化。有些用户的加载时间确实更长，但标准文件共享的总体平均值约为 15.84。这个加载时间刚好是 7.25 秒的总体高级加载时间的两倍多。
结果分析
正确配置后，Azure Files 在管理最终用户配置文件方面表现非常出色。测试结果表明，在我们的工作负载中，高级文件共享似乎在不同级别提供了最佳的总体一致性能。此性能附带了高级套餐定价的额外成本。虽然高级文件共享确实表现良好，但使用配置文件容器技术可能会更好地执行。
Citrix 资料管理器配置选项
当用户从不同设备打开多个配置文件时，最好使用 Citrix Profile Manager 以防止“最后写入胜利”场景。当用户打开多个会话时，此功能可在登录之间保持配置文件的一致性。但是，在 Citrix 中使用 Azure 文件时，建议使用其他一些功能来改善用户体验。
尽可能启用文件夹重定向。如图表所示，启用文件夹重定向可防止将大量数据从 Azure 文件复制到 Citrix 主机。文件夹重定向旨在减少登录/注销时的网络流量，这极大地改善了用户登录体验并降低了部署成本。复制到 Citrix 主机的数据较少意味着连接到 Citrix 主机以存储用户配置文件的存储空间更小（且成本更低）。当 Citrix 主机驻留在 Azure 中时，连接到 Azure 文件的延迟很小，用户体验不受影响。当 Citrix 主机在本地时，重定向将节省离开 Azure 的应计费出口流量。
启用 Citrix 配置文件管理器的大文件处理功能是改善用户登录体验的绝佳方法。通过直接在配置文件存储中更新大型文件而不是在登录时将其复制下来，来缩短登录时间。由于 Microsoft 不建议将 PST 和 OST 文件存储在重定向的文件夹中，因此使用大文件处理来提供与文件夹重定向相同的好处。Citrix 配置文件管理器会创建指向该文件的符号链接，因此在打开或更新文件时，文件操作将重定向到 Azure 文件中的用户存储。此功能允许 PST 和 OST 文件保留在远程文件共享上的用户配置文件中，同时被视为本地文件。上图显示了对事务和高级文件共享启用和禁用大型文件支持之间的出口流量的区别。
更高版本的 CPM 默认情况下可在 Citrix 服务器上启用配置文件流式传此技术可防止在登录时将整个用户配置文件下载到 Citrix 主机。相反，只列举位于配置文件中的文件列表，操作系统可以使用该列表。请求文件时，将从用户存储中提取该文件并将其带到 Citrix 主机。此过程可减少登录时发生的文件副本数量，并改善用户登录体验。
选择性能层
当您的吞吐量和 IOPS 要求分别低于支持的 300 MiB/ 秒和 10,000 IOPS 的水平时，结果支持使用事务优化的文件共享。在不同存储帐户之间创建多个文件共享以托管用户的配置文件数据，分配负载。
注意：建议的最佳做法是每个存储帐户只有一个事务优化的文件共享。此建议是因为在正常使用下两个或多个事务优化的文件共享可能会超过单个存储帐户的最大限制。有关详细信息，请参阅 可扩展性和性能目标
如果使用更高性能的高级层来获得一致的性能和更低的延迟，请在确定最终规模之前进行一些基准测试。进行基准测试的最佳方法是使用 100 TiB 高级文件共享运行最密集的基准测试，并监控事务、吞吐量和延迟指标。使用该信息可以确定所需性能级别的预配置存储量。
注意：如果文件共享有大量小文件频繁更新，则 Azure Files 可能会由于元数据过多而导致文件的读取和写入延迟。如果在文件共享上观察到限制，也可能发生这种延迟。如果您遇到限制，Azure 文件共享上的成功服务器延迟度量显示稳步增长。一旦该指标超过 15 毫秒，用户体验就会明显下降。
最后，选择性能层将归结为确定您的预期响应时间和冗余要求。如果用户响应时间需要低于 10 毫秒，则高级层文件共享将提供一致的响应时间。在我们的测试配置中，此响应时间转换为配置文件加载时间不到 10 秒。如果您的用户接受的响应时间超过 10 毫秒，那么您可以使用更具成本效益的事务优化文件共享。为了提供最佳的用户体验，请使用多个存储帐户来分配负载。
使用本文中提供的数据确定组织的最佳配置，并使用自己的工作负载测试 Azure 文件的性能。
通过私有终端节点和 RBAC 权限保护访问
Azure 文件提供了两种主要类型的端点来访问 Azure 文件共享：
-
公共终端节点，具有公共 IP 地址，可以 从世界任何地方访问。
-
私有终端节点，存在于虚拟网络中，并且具有 该虚拟网络地址空间内的 专用 IP 地址。
考虑到文件共享用于用户配置文件和数据，我们建议只能在 Azure VNET 中通过 私有端点访问该文件共享。有关详细说明，请使用 以下链接。
配置私有终端节点后，按照文档中的概述，验证来自 Azure VNET 中的虚拟机的辅助功能。
下一步是通过 RBAC 锁定权限。按照为用户个性化层设置 Azure 文件存储和 Citrix Profile Management 中的指导进行操作。
保护数据
将用户数据存储在 Azure 文件中后，您需要防止备份和丢失。本节提供了两个内置功能的指导：软删除和 Azure 备份，它们提供数据保护，此外还提供了创建存储帐户时可用的存储帐户冗余选项。
软删除
软删除是 Azure 的一项功能，它允许您恢复被用户意外删除的文件，而无需经过复杂的还原过程。可以在存储帐户的文件服务部分中启用软删除。除了启用软删除外，您还可以通过软删除功能设置已删除文件的可用天数。
Azure 备份
使用高级层或在事务优化中启用大型文件共享时，数据复制仅限于本地冗余存储和区域冗余存储。如果没有大型文件共享，您还可以使用 Geo 冗余存储，但这将共享限制为 5 TiB、60 MiB/s 和 1000 IOPS。Azure 备份还提供了通过 Azure 文件快照保护数据的可靠方法。您可以使用 Azure 备份通过 Azure 备份保管库中的配置选项来设置保留时间表。
由于 Azure 备份使用快照来保护您的数据，因此不要删除这些快照，否则您可能会丢失恢复点并且无法恢复。为防止意外删除，Azure 备份会锁定存储帐户。如果删除该锁定并删除共享，则所有备份和快照也将被删除，并且所有数据都将丢失。
除此之外，许多第三方供应商还提供可用于备份 Azure Files 数据的解决方案。
迁移文件
可以通过多种不同的方法将用户数据文件迁移到 Azure 文件中。在选择迁移策略之前，您需要确定数据量、文件共享的目标数量以及用户数据存储的目标结构。
哪种方法最适合您取决于数据当前驻留在网络中的位置。没有一家企业是相同的，各企业之间的文件迁移过程差别很大。移动文件的方法有多种；通常情况下，您最终会使用多种方法来实现所需的迁移。
-
Azure 文件同步： 任何运行 Windows Server 2012 R2 或更高版本的 Windows 服务器都可以安装 Azure 文件同步代理。然后，代理将从 Windows 服务中将用户数据文件上载到 Azure 文件。如果出站网络未受限制，代理通常每两天可以移动约 1 TB。使用 Azure 文件同步，NTFS 权限、访问控制列表 (ACL) 和文件元数据将被保留。
-
存储迁移服务： 存储迁移服务 (SMS) 专为帮助您将数据从 Windows 服务器迁移到 Azure 而设计。该服务可以清点现有服务器，传输数据，甚至假定源服务器的身份，以便更轻松地对最终用户进行直接转换。
-
Microsoft Data Box 磁盘： Microsoft Data Box 磁盘是一款 8 TB SSD 闪存驱动器，最多可堆叠 5 倍，总容量为 40 TB。Data Box 磁盘支持 AES-128 加密，并依赖于 Robocopy 等文件复制实用程序来传输数据。
-
Microsoft Data Box： Microsoft Data Box 是一种脱机文件传输解决方案，它使用诸如 Robocopy 等常见的文件传输实用程序将数据从服务器安全地移动到 Data Box。然后，Data Box 将发送到Microsoft 并直接上载到 Azure 文件中。Microsoft Data Box 有 2 种规格，100 TB 和 1 PB。两种设备都存储加密的数据 (AES-256)，以便在本地数据中心和 Azure 数据中心之间传输时对其进行保护。Microsoft Data Box 支持中小型企业和 NFS NAS 协议。
-
Data Box 网关： 在 Hyper-V 或 VMware 上运行的虚拟设备，充当 Azure 文件支持的存储代理服务器。本地用户通过 SMB 或 NFS 协议访问它，网关接受数据并通过互联网将其传输到 Azure 文件。Data Box 网关提供了从本地服务器到 Azure 文件的连续数据流。
-
存储资源管理器： 最新版本的存储资源管理器使用 AZCOPY 显著加快文件传输速度。如果您想自动化数据传输，存储资源管理器甚至可以为您提供 AZCOPY 命令字符串。
-
AZCOPY： Azure 命令行实用程序，允许您在存储位置之间移动数据，包括本地文件服务器和 Azure 中的存储帐户。
-
RoboCopy： 可靠的文件复制实用程序，可在传输过程中保留所有文件属性、权限和 ACL。
除了这些文件传输/复制解决方案之外，许多第三方供应商还提供可用于将数据迁移到 Azure Files 的解决方案。有关最佳迁移路径的详细信息，请参阅 迁移到 Azure 文件共享。
结论
强烈建议将 Azure 文件与 Azure 中的 Citrix 部署结合使用。Azure Files 提供了用户配置文件数据的高可用性，而不需要复杂的基础如果用户可以接受延迟和网络性能，Azure 文件也可以用于本地部署。
Citrix 配置文件管理器与 Azure 文件一起使用时可提供多项这些好处包括使用配置文件流和大型文件处理来减少从用户配置文件存储复制到 Citrix 主机的数据量。
在大多数情况下，对 Azure 文件使用事务优化层就足够了。特别是，如果您可以将负载分配到多个共享和目标工作负载，使单个共享的每小时更新文件数量保持在 100,000 左右。对于低延迟、高响应时间要求（用户需要延迟始终保持在 10 毫秒以下），请参阅使用 Azure Files 的高级层。
引用
本文引用了以下文档中的内容：