计划部署 Azure 文件
可通过两种主要方式部署 Azure 文件存储：直接装载无服务器 Azure 文件共享，或使用 Azure 文件同步在本地缓存 Azure 文件共享。部署注意事项根据所选的选项而异。
直接装载 Azure 文件共享：由于 Azure 文件存储提供服务器消息块 (SMB) 或网络文件系统 (NFS) 访问，因此你可使用操作系统中提供的标准 SMB 或 NFS 客户端在本地或云中装载 Azure 文件共享。 由于 Azure 文件共享是无服务器的，因此针对生产方案进行部署不需要管理文件服务器或 NAS 设备。 这意味着无需应用软件修补程序或换出物理磁盘。
使用 Azure 文件同步在本地缓存 Azure 文件共享：借助 Azure 文件同步，可以在 Azure 文件存储中集中管理组织的文件共享，同时又能保留本地文件服务器的灵活性、性能和兼容性。 Azure 文件同步可将本地（或云中的）Windows Server 转换为 SMB Azure 文件共享的快速缓存。
本文主要阐述有关部署可供本地或云客户端直接装载的 Azure 文件共享时的部署注意事项。 若要规划 Azure 文件同步部署，请参阅规划 Azure 文件同步部署。
可用的协议
Azure 文件存储提供两种行业标准文件系统协议用于装载 Azure 文件共享：服务器消息块 (SMB) 协议和网络文件系统 (NFS) 协议，你可以选择最适合你的工作负载的协议。 尽管可以在同一存储帐户中创建 SMB 和 NFS Azure 文件共享，但 Azure 文件共享不支持在同一个文件共享中同时使用 SMB 和 NFS 协议。 目前只有新的 FileStorage 存储帐户类型中支持 NFS 4.1（仅限高级文件共享）。
对于 SMB 和 NFS 文件共享，Azure 文件存储提供企业级文件共享，这些共享可以纵向扩展以满足你的存储需求，并且可同时由数千个客户端访问。
| 功能 | SMB | NFS |
|---|---|---|
| 支持的协议版本 | SMB 3.1.1、SMB 3.0、SMB 2.1 | NFS 4.1 |
| 推荐的操作系统 |
|
Linux 内核版本 4.3+ |
| 可用层 | 高级、事务优化、热和冷 | 高级 |
| 计费模式 | 预配的容量 | |
| 冗余 | LRS、ZRS、GRS、GZRS | LRS、ZRS |
| 文件系统语义 | Win32 | POSIX |
| 身份验证 | 基于标识的身份验证 (Kerberos)、共享密钥身份验证 (NTLMv2) | 基于主机的身份验证 |
| 授权 | Win32 样式访问控制列表 (ACL) | UNIX 样式权限 |
| 事例敏感性 | 不区分大小写，但保留大小写 | 区分大小写 |
| 删除或修改打开的文件 | 仅使用锁定 | 是 |
| 文件共享 | Windows 共享模式 | 字节范围的公告网络锁管理器 |
| 硬链接支持 | 不支持 | 支持 |
| 符号链接支持 | 不支持 | 支持 |
| （可选）可通过 Internet 访问 | 是（仅限 SMB 3.0+） | 否 |
| 支持 FileREST | 是 | 子网： |
| 强制字节范围锁 | 支持 | 不支持 |
| 顾问字节范围锁 | 不支持 | 支持 |
| 扩展/命名属性 | 不支持 | 不支持 |
| 备用数据流 | 不支持 | 空值 |
| 对象标识符 | 不支持 | 空值 |
| 重分析点 | 不支持 | 空值 |
| 稀疏文件 | 不支持 | 空值 |
| 压缩 | 不支持 | 空值 |
| Named pipes | 不支持 | 空值 |
| SMB 直通 | 不支持 | 空值 |
| SMB 目录租用 | 不支持 | 空值 |
| 卷影复制 | 不支持 | 空值 |
| 短文件名（8.3 别名） | 不支持 | 空值 |
| 服务器服务 | 不支持 | 空值 |
| 文件系统事务 (TxF) | 不支持 | 空值 |
管理概念
Azure 文件共享将部署到存储帐户。存储帐户是代表存储共享池的顶级对象。 此存储池可用于部署多个文件共享和其他存储资源，例如 Blob 容器、队列或表。 部署到存储帐户中的所有存储资源共享应用于该存储帐户的限制。 若要了解当前存储帐户限制，请参阅 Azure 文件存储的可伸缩性和性能目标。
对于 Azure 文件存储部署，将使用两种主要类型的存储帐户：
- 常规用途版本 2 (GPv2) 存储帐户：使用 GPv2 存储帐户可以在标准的/基于硬盘（基于 HDD）的硬件上部署 Azure 文件共享。 除了存储 Azure 文件共享以外，GPv2 存储帐户还可以存储其他存储资源，例如 Blob 容器、队列或表。
- FileStorage 存储帐户：使用 FileStorage 存储帐户可以在高级/基于固态磁盘（基于 SSD）的硬件上部署 Azure 文件共享。 FileStorage 帐户只能用于存储 Azure 文件共享；其他存储资源（Blob 容器、队列、表等）都不能部署在 FileStorage 帐户中。 只有 FileStorage 帐户可同时部署 SMB 和 NFS 文件共享。
在 Azure 门户、PowerShell 或 CLI 中，可能会遇到一些其他的存储帐户类型。 两种存储帐户类型（BlockBlobStorage 和 BlobStorage 存储帐户）不能包含 Azure 文件共享。 可能会看到的其他两个存储帐户类型为常规用途版本 1 (GPv1) 和经典存储帐户，二者都可以包含 Azure 文件共享。 尽管 GPv1 和经典存储帐户可以包含 Azure 文件共享，但 Azure 文件存储的大多数新功能只能在 GPv2 和 FileStorage 存储帐户中使用。 因此，我们建议仅将 GPv2 和 FileStorage 存储帐户用于新部署，而升级 GPv1 和经典存储帐户的前提是它们已经存在于环境中。
将 Azure 文件共享部署到存储帐户时，我们建议：
仅将 Azure 文件共享部署到已包含其他 Azure 文件共享的存储帐户。 尽管 GPv2 存储帐户允许使用混合用途的存储帐户，但由于 Azure 文件共享和 Blob 容器等存储资源共享存储帐户的限制，因此，将资源混合在一起可能会导致将来更难以排查性能问题。
部署 Azure 文件共享时请注意存储帐户的 IOPS 限制。 理想情况下，应该以 1:1 的形式将文件共享与存储帐户相映射。 但是，由于组织和 Azure 施加各种限制和制约，不一定总能实现这种映射。 无法在一个存储帐户中部署一个文件共享时，请考虑哪些共享高度活跃，哪些共享不够活跃，以确保不会将访问量最大的文件共享一起放到同一存储帐户中。
仅部署 GPv2 帐户和 FileStorage 帐户，并在环境中找到 GPv1 帐户和经典存储帐户后对其进行升级。
标识
若要访问某个 Azure 文件共享，该文件共享的用户必须完成身份验证，并已获得授权。 这种授权是根据访问文件共享的用户的标识完成的。 Azure 文件存储支持以下身份验证方法：
- 本地 Active Directory 域服务（AD DS 或本地 AD DS）：Azure 存储帐户可以“域加入”到客户拥有的 Active Directory 域服务，就像 Windows Server 文件服务器或 NAS 设备一样。 你可以在本地、在 Azure VM 中部署域控制器，甚至可以部署为其他云服务提供商中的 VM；Azure 文件存储与域控制器的托管位置无关。 存储帐户加入域后，最终用户可以使用其登陆电脑的用户帐户装载文件共享。 基于 AD 的身份验证使用 Kerberos 身份验证协议。
- Microsoft Entra 域服务：Microsoft Entra 域服务提供可用于 Azure 资源的 Microsoft 托管的域控制器。 将你的存储帐户加入 Microsoft Entra 域服务的域，可获得加入客户拥有的 AD DS 的域类似的好处。 此部署选项最适用于需要基于 AD 的权限的应用程序直接迁移方案。 由于 Microsoft Entra 域服务提供了基于 AD 的身份验证，因此此选项还使用 Kerberos 身份验证协议。
- 用于混合标识的 Microsoft Entra Kerberos：Microsoft Entra Kerberos 允许你使用 Microsoft Entra ID 对混合用户标识进行身份验证，这些标识是已同步到云的本地 AD 标识。 此配置使用 Microsoft Entra ID 发出 Kerberos 票证，以通过 SMB 协议访问文件共享。 这意味着你的最终用户可以通过 Internet 访问 Azure 文件共享，而无需从 Microsoft Entra 混合联接 VM 和 Microsoft Entra 联接 VM 通过网络连接到域控制器。
- Linux 客户端通过 SMB 进行 Active Directory 身份验证：Azure 文件存储支持 Linux 客户端通过 SMB 进行基于标识的身份验证，方法是通过 AD DS 或 Microsoft Entra 域服务使用 Kerberos 身份验证协议。
- Azure 存储帐户密钥：还可以使用 Azure 存储帐户密钥装载 Azure 文件共享。 若要以这种方式装载文件共享，需使用存储帐户名称作为用户名，使用存储帐户密钥作为密码。 使用存储帐户密钥装载 Azure 文件共享实际上是一项管理员操作，因为装载的文件共享对其上的所有文件和文件夹拥有完全权限，即使对这些文件和文件夹应用了 ACL。 使用存储帐户密钥通过 SMB 装载时，将使用 NTLMv2 身份验证协议。 如果要使用存储帐户密钥来访问 Azure 文件共享，我们建议使用网络部分所述的专用终结点或服务终结点。
对于从本地文件服务器迁移的客户，或在 Azure 文件存储中创建新的文件共享旨在使其行为方式类似于 Windows 文件服务器或 NAS 设备，建议选择将存储帐户加入到“客户拥有的 AD DS”的域。 若要详细了解如何将存储帐户加入到客户拥有的 AD DS 的域，请参阅概述 - 通过 SMB 为 Azure 文件共享启用本地 Active Directory 域服务身份验证。
网络
直接装载 Azure 文件共享通常需要在网络配置方面经过一些考量，因为：
- 许多组织和 Internet 服务提供商 (ISP) 往往会阻止 SMB 文件共享使用通信端口 445 传送出站 (internet) 流量。
- NFS 文件共享依赖于网络级身份验证，因此只能通过受限网络进行访问。 使用 NFS 文件共享始终需要完成某种级别的网络配置。
为了配置网络，Azure 文件存储提供了一个可从 Internet 访问的公共终结点以及与 Azure 网络功能的集成。这些功能包括可帮助将公共终结点限制为指定虚拟网络的服务终结点，以及为存储帐户分配虚拟网络 IP 地址空间中某个专用 IP 地址的专用终结点。 虽然使用公共终结点或服务终结点不产生额外费用，但专用终结点会产生标准数据处理费用。
这意味着需要考虑以下网络配置：
- 如果所需的协议是 SMB，并且通过 SMB 进行的所有访问都从 Azure 中的客户端发起，则不需要完成特殊的网络配置。
- 如果所需的协议是 SMB，并且访问从本地客户端发起，则需要通过 VPN 或 ExpressRoute 从本地连接到 Azure 网络，并使用专用终结点在内部网络中公开 Azure 文件存储。
- 如果所需的协议是 NFS，则可以使用服务终结点或专用终结点将网络限制为指定的虚拟网络。 如果你需要静态 IP 地址和/或你的工作负载需要高可用性，请使用专用终结点。 使用服务终结点时，区域性中断等罕见情况可能会导致存储帐户的基础 IP 地址发生变化。 虽然文件共享上仍提供数据，但客户端需要重新装载共享。
若要详细了解如何为 Azure 文件存储配置网络，请参阅 Azure 文件存储网络注意事项。
除了使用公共终结点直接连接到文件共享或使用专用终结点通过 VPN/ExpressRoute 连接到文件共享以外，SMB 还提供了一种附加的客户端访问策略：SMB over QUIC。 使用 SMB over QUIC，无需配置“SMB VPN”即可通过 QUIC 传输协议进行 SMB 访问。 尽管 Azure 文件存储不直接支持 SMB over QUIC，但你可以使用 Azure 文件同步在 Windows Server 2022 Azure Edition VM 上创建 Azure 文件共享的轻型缓存。若要详细了解此选项，请参阅将 SMB over QUIC 与 Azure 文件同步配合使用。
Encryption
Azure 文件存储支持两种不同类型的加密：
- 传输中加密，它与装载/访问 Azure 文件共享时使用的加密相关
- 静态加密，它与数据存储在磁盘时的加密方式相关
传输中加密
重要
本部分介绍 SMB 共享的传输中加密详细信息。 有关通过 NFS 共享进行传输中加密的详细信息，请参阅安全性和网络。
默认情况下，所有 Azure 存储帐户均已启用传输中加密。 即通过 SMB 装载文件共享或通过 FileREST 协议（例如，通过 Azure门户、PowerShell/CLI 或 Azure SDK）访问文件共享时，Azure 文件存储仅允许通过加密或 HTTPS 使用 SMB 3.x 及更高版本建立的连接。 如果启用了传输中加密，不支持 SMB 3.x 的客户端或支持 SMB 3.x 但不支持 SMB 加密的客户端将无法装载 Azure 文件共享。 若要详细了解哪些操作系统支持具有加密功能的 SMB 3.x，请参阅适用于 Windows、macOS 和 Linux 的文档。 PowerShell、CLI 和 SDK 的所有当前版本均支持 HTTPS。
可以为 Azure 存储帐户禁用传输中加密。 禁用加密后，Azure 文件存储还将允许没有加密功能的 SMB 2.1 和 SMB 3.x，以及通过 HTTP 进行的未加密 FileREST API 调用。 禁用传输中加密的主要原因是为了支持必须在更低版本的操作系统（例如，Windows Server 2008 R2 或更低版本的 Linux 发行版）上运行的旧版应用程序。 Azure 文件存储仅允许在与 Azure 文件共享相同的 Azure 区域内建立 SMB 2.1 连接；Azure 文件共享的 Azure 区域之外的 SMB 2.1 客户端（例如，本地或其他 Azure 区域）将无法访问文件共享。
强烈建议确保启用了传输中数据的加密。
有关传输中加密的详细信息，请参阅要求在 Azure 存储中进行安全传输。
静态加密
使用 Azure 存储服务加密 (SSE) 对存储在 Azure 文件存储中的所有数据进行静态加密。 存储服务加密的工作方式类似于 Windows 上的 BitLocker：在文件系统级别下对数据进行加密。 由于数据在 Azure 文件共享的文件系统下加密，因此，在将数据编码到磁盘时，无需访问客户端上的基础密钥即可读取或写入 Azure 文件共享。 静态加密同时适用于 SMB 和 NFS 协议。
默认情况下，Azure 文件存储中存储的数据使用 Microsoft 管理的密钥进行加密。 使用 Microsoft 托管密钥，Azure 保存用于加密/解密数据的密钥，并负责定期轮换这些密钥。 你还选择管理你自己的密钥，这让你能够控制密钥轮换过程。 如果你选择使用客户管理的密钥来加密你的文件共享，则 Azure 文件存储可访问你的密钥来执行来自你的客户端的读取和写入请求。 通过客户管理的密钥，你可随时撤销此授权，但撤销意味着将无法再通过 SMB 或 FileREST API 访问你的 Azure 文件共享。
Azure 文件存储预其他 Azure 存储服务（例如 Azure Blob 存储）使用相同的机密方案。 要详细了解 Azure 存储服务加密 (SSE)，请参阅针对静态数据的 Azure 存储加密。
数据保护
Azure 文件有一种多层方法来确保数据得到备份、恢复以及不受安全威胁。 请参阅 Azure 文件存储数据保护概述。
软删除
软删除是存储帐户级别设置，可让你在意外删除文件共享时恢复文件共享。 已删除的文件共享会过渡到软删除状态，而非被永久擦除。 可以配置软删除的共享被永久删除前的可恢复时间，并在此保留期内随时取消删除共享。
对于新存储帐户，默认情况下软删除处于启用状态。 如果你的工作流中共享删除是常见且预期的，那么你可能会设置很短的保留期，或者根本不启用软删除。
有关软删除的详细信息，请参见防止意外数据删除。
备份
可以通过共享快照备份 Azure 文件共享，这些快照是共享的只读时间点副本。 快照是增量的，这意味着它们只包含自上一个快照以来更改的数据量。 每个文件共享最多可以有 200 个快照，并将其保留长达 10 年。 可以通过 PowerShell 或命令行接口 (CLI) 在 Azure 门户中手动拍摄快照，或使用 Azure 备份。
Azure 文件共享的 Azure 备份处理快照的计划和保留。 其祖父-父-子 (GFS) 功能意味着你可以生成每日、每周、每月和每年的快照，每个快照都具有自己不同的保持期。 Azure 备份还会协调启用软删除，并在存储帐户中任何文件共享配置为用于备份时，立即对存储帐户添加删除锁定。 最后，Azure 备份提供某些关键的监视和警报功能，使客户能够获得其备份空间的合并视图。
可以使用 Azure 备份在 Azure 门户中执行项目级和共享级还原。 只需选择还原点（特定快照）、特定文件或目录（如相关），然后选择要还原到的位置（原始或备用）。 备份服务会处理复制快照数据，并在门户中显示还原进度。
存储层
Azure 文件存储提供两个不同的存储层：SSD（固态磁盘）和 HDD（硬盘驱动器），使你能够根据方案的性能和价格要求定制共享：
SSD（高级）：对于大多数 IO 操作和大多数 IO 密集型工作负荷，SSD 文件共享可以提供稳定的高性能和 10 毫秒以下的低延迟。 SSD 文件共享适合于各种各样的工作负荷，例如数据库、网站托管和开发环境。 SSD 文件共享可与服务器消息块 (SMB) 和网络文件系统 (NFS) 协议结合使用。 SSD 文件共享在预配的 v1 计费模型中可用。 SSD 文件共享提供比 HDD 文件共享更高的可用性 SLA（请参阅“Azure 文件存储高级层”）。
HDD（标准）：HDD 文件共享为通用文件共享提供了一种经济高效的存储选项。 HDD 文件共享可用于 即用即付计费模型。
为工作负载选择介质层时，请考虑性能和使用要求。 如果你的工作负荷要求延迟不超过 10 毫秒，或者你在本地使用 SSD 存储介质，则 SSD 文件共享层可能是最合适的。 如果低延迟不那么令人担忧，例如从 Azure 在本地安装团队共享或使用 Azure 文件同步在本地缓存，则从成本角度来看，HDD 文件共享可能更合适。
在存储帐户中创建文件共享后，你无法直接将其移到其他介质层。 例如，要将 HDD 文件共享移到 SSD 介质层，你必须创建新的 SSD 文件共享，并将数据从原始共享复制到 FileStorage 帐户中的新文件共享。 建议在 Azure 文件共享之间使用 AzCopy 来复制数据，但你也可使用工具，例如适合 Windows 的 robocopy，或者适合 macOS 和 Linux 的 rsync。
有关详细信息，请参阅了解 Azure 文件存储计费。
冗余
为了在 Azure 文件共享中保护数据以防数据丢失或损坏，Azure 文件存储会在写入每个文件时存储该文件的多个副本。 根据你的需求，可以选择不同程度的冗余。 Azure 文件存储目前支持以下数据冗余选项：
- 本地冗余存储 (LRS) ：使用 LRS 时，每个文件在 Azure 存储群集中存储三次。 这可以防止由于硬件故障（例如磁盘驱动器损坏）而导致数据丢失。 但如果数据中心内发生火灾或洪水等灾难，则使用 LRS 的存储帐户的所有副本可能会丢失或无法恢复。
- 区域冗余存储 (ZRS)：使用 ZRS，每个文件会存储三个副本。 但这些副本以物理方式隔离在不同 Azure 可用性区域的三个不同的存储群集中。 可用性区域是 Azure 区域中独特的物理位置。 每个区域由一个或多个数据中心组成，这些数据中心配置了独立电源、冷却和网络。 在将副本写入所有三个可用性区域的存储群集前，不允许将其写入存储。
- 异地冗余存储 (GRS)：使用 GRS 时，你会拥有两个区域，即一个主要区域和一个次要区域。 文件在主要区域中的 Azure 存储群集中存储三次。 写入将异步复制到 Azure 定义的次要区域。 GRS 提供分布在两个 Azure 区域之间的六个数据副本。 如果由于自然灾害或其他类似事件导致重大灾难（如某个 Azure 区域永久丢失），Azure 会执行故障转移。 在这种情况下，次要区域将成为主要区域，以满足所有操作需求。 由于主要区域和次要区域之间的复制是异步的，因此，在发生重大灾难时，尚未复制到次要区域的数据将会丢失。 还可以执行异地冗余存储帐户的手动故障转移。
- 异地区域冗余存储 (GZRS)：可以将 GZRS 视为具有异地冗余的 ZRS。 使用 GZRS，文件在主要区域的三个不同存储群集中存储三次。 所有写入都将异步复制到 Microsoft 定义的次要区域。 GZRS 的故障转移过程的工作原理与 GRS 相同。
不超过 5 TiB 的标准 Azure 文件共享支持全部 4 种冗余类型。 大于 5 TiB 的标准文件共享仅支持 LRS 和 ZRS。 高级 Azure 文件共享仅支持 LRS 和 ZRS。
常规用途版本 2 (GPv2) 存储帐户提供了 Azure 文件存储不支持的另外两个冗余选项：读取可访问的异地冗余存储 (RA-GRS) 和读取可访问的异地区域冗余存储 (RA-GZRS)。 可以在存储帐户中使用这些选项集预配 Azure 文件共享，但 Azure 文件存储不支持从次要区域读取。 部署到 RA-GRS 或 RA-GZRS 存储帐户中的 Azure 文件共享分别按 GRS 或 GZRS 计费。
有关冗余的详细信息，请参阅 Azure 文件存储数据冗余。
标准 ZRS 可用性
适用于标准常规用途 v2 存储帐户的 ZRS 可在一部分 Azure 区域中使用。
高级 ZRS 可用性
适用于高级文件共享的 ZRS 可在一部分 Azure 区域中使用。
标准 GZRS 可用性
GZRS 可在一部分 Azure 区域中使用。
灾难恢复和故障转移
在发生计划外的区域服务中断的情况下，应该为 Azure 文件共享制定灾难恢复 (DR) 计划。 要了解 DR 和存储帐户故障转移所涉及的概念和过程，请参阅 Azure 文件存储的灾难恢复和故障转移。
迁移
在很多情况下，你不想要为组织建立全新的文件共享，而是将现有文件共享从本地文件服务器或 NAS 设备迁移到 Azure 文件存储。 为你的场景选择正确的迁移策略和工具对于迁移的成功非常重要。
迁移概述文章简要介绍了基础知识，并包含一个表格，指引你查看适用于你的方案的迁移指南。