计划部署 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 订阅和资源组中创建和配置的可管理项。 资源由资源提供程序提供，后者是提供特定类型资源的管理服务。

资源提供程序提供的存储帐户Microsoft.Storage。 存储帐户是表示存储、IOPS 和吞吐量共享池的顶级资源，你可以根据存储帐户类型在其中部署经典文件共享或其他存储资源。 部署到存储帐户中的所有存储资源共享应用于该存储帐户的限制。 经典文件共享支持 SMB 和 NFS 文件共享协议。

经典文件共享 (Microsoft.Storage)

经典文件共享或部署在存储帐户中的文件共享是为 Azure 文件存储部署文件共享的传统方法。 它们支持 Azure 文件存储支持的所有关键功能，包括每个区域中的 SMB 和 NFS、SSD 和 HDD 介质层、每个冗余类型。 虽然经典文件共享支持 Azure 文件存储功能的全部范围，但它们具有重要的关键限制：

• 容量计划：经典文件共享和其他存储服务（如 Blob 容器）的子对象位于同一存储帐户中，共享一个通用的存储池、IOPS 和吞吐量。 这意味着在存储帐户中放置多个经典文件共享需要进行规划，避免达到容量瓶颈。 当规划经典文件共享的容量时，需要考虑存储帐户中放置的每个经典文件共享的当前和未来需求，因为一个经典文件共享的增长可能会将其他文件共享挤出。

• 共享设置：许多重要设置（如网络与安全规则）在存储帐户级别应用，因此，将经典文件共享放置在同一存储帐户中需要仔细考虑。 如果你愿意让存储帐户具有相同的安全设置，则应将存储帐户视为信任边界，并且仅将经典文件共享放置在同一存储帐户中。

• 缩放复杂性：由于 Microsoft.Storage 资源提供程序对存储帐户的约束，Azure 文件的大规模部署可能需要管理许多 Azure 订阅。 请参阅存储帐户限制，了解更多信息。

有两种用于经典文件共享部署的主要存储帐户：

• 预配的存储帐户：使用存储帐户类型区分 FileStorage 预配的存储帐户。 预配的存储帐户允许在基于 SSD 或 HDD 的硬件上部署预配的经典文件共享。 预配的存储帐户只能用于存储经典文件共享，不能用于存储其他存储资源，例如 Blob 容器、队列和表。 建议对所有新的经典文件共享部署使用预配的存储帐户。
• 按需付费存储帐户：通过StorageV2存储帐户类型可以将这些帐户区分为按需付费存储帐户。 使用即用即付存储帐户，可以在基于 HDD 的硬件上部署即用即付文件共享。 即用即付存储帐户可用于存储经典文件共享和其他存储资源，例如 Blob 容器、队列或表。

若要了解详细信息，请参阅创建经典文件共享。

可用的协议

Azure 文件存储提供两种行业标准文件系统协议用于装载 Azure 文件共享：服务器消息块 (SMB) 协议和网络文件系统 (NFS) 协议，你可以选择最适合你的工作负载的协议。 尽管可以在同一存储帐户中创建 SMB 和 NFS Azure 文件共享，但 Azure 文件共享不支持在同一个文件共享中同时使用 SMB 和 NFS 协议。

对于 SMB 和 NFS 文件共享，Azure 文件存储提供企业级文件共享，这些共享可以纵向扩展以满足你的存储需求，并且可同时由数千个客户端访问。

Identity

若要访问某个 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 域服务，可获得与域加入到客户拥有的 Active Directory 域服务类似的好处。 此部署选项最适用于需要基于 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 身份验证协议。 在几乎所有情况下，我们建议使用 基于标识的身份验证 而不是存储帐户密钥来访问 SMB Azure 文件共享。 但是，如果必须使用存储帐户密钥，我们建议使用专用终结点或服务终结点，如 “网络 ”部分中所述。

对于从本地文件服务器迁移的客户，或在 Azure 文件存储中创建新的文件共享以使其行为与 Windows 文件服务器或 NAS 设备类似的客户，建议将存储帐户“域加入”到客户拥有的 Active Directory 域服务。 若要详细了解如何将存储账户加入由客户所有的 AD DS 域，请参阅概述 - 通过 SMB 为 Azure 文件共享进行本地 Active Directory 域服务身份验证。

网络

直接装载 Azure 文件共享通常需要在网络配置方面经过一些考量，因为：

• 许多组织和互联网服务提供商 (ISP) 往往会阻止使用端口 445 进行通信的 SMB 文件共享的出站（互联网）流量。
• 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 文件共享时使用的加密相关
• 静态加密，它与数据存储在磁盘时的加密方式相关

传输中加密

默认情况下，所有 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 文件存储中的所有数据进行静态加密。 SSE 的工作方式类似于 Windows 上的 BitLocker：在文件系统级别下对数据进行加密。

数据在 Azure 文件共享的文件系统下加密，因此，在将数据编码到磁盘时，无需访问客户端上的基础密钥即可读取或写入 Azure 文件共享。 静态加密同时适用于 SMB 和 NFS 协议。

默认情况下，Azure 文件存储中存储的数据使用 Microsoft 管理的密钥进行加密。 使用Microsoft管理的密钥，Azure 保存用于加密和解密数据的密钥。 Azure 负责定期轮换这些密钥。

你还选择管理你自己的密钥，这让你能够控制密钥轮换过程。 如果你选择使用客户管理的密钥来加密你的文件共享，则 Azure 文件存储可访问你的密钥来执行来自你的客户端的读取和写入请求。 有了客户管理的密钥，你可以随时撤销此授权。 但是，如果没有此授权，Azure 文件共享将无法再通过 SMB 或 FileREST API 进行访问。

Azure 文件存储与其他 Azure 存储服务（例如 Azure Blob 存储）使用相同的加密方案。 要详细了解 Azure 存储 SSE，请参阅针对静态数据的 Azure 存储加密。

数据保护

Azure 文件有一种多层方法来确保数据得到备份、恢复以及不受安全威胁。 请参阅 Azure 文件存储数据保护概述。

软删除

软删除是一种存储帐户级别设置，使你在意外删除文件共享时对其进行恢复。 已删除的文件共享会过渡到软删除状态，而非被永久擦除。 可以配置软删除的共享被永久删除前的可恢复时间，并在此保留期内随时取消删除共享。

对于新存储帐户，默认情况下软删除处于启用状态。 如果你的工作流中共享删除是常见且预期的，那么你可能会设置很短的保留期，或者根本不启用软删除。

有关软删除的详细信息，请参见防止意外数据删除。

备份

可以通过共享快照备份 Azure 文件共享，这些快照是共享的只读时间点副本。 快照是增量的，这意味着它们只包含自上一个快照以来更改的数据量。 每个文件共享最多可以有 200 个快照，并将其保留长达 10 年。 可以通过 PowerShell 或命令行接口 (CLI) 在 Azure 门户中手动拍摄快照，或使用 Azure 备份。

Azure 备份服务用于 Azure 文件共享，负责快照的计划和保留。 其祖父-父-子 (GFS) 功能意味着你可以生成每日、每周、每月和每年的快照，每个快照都具有自己不同的保持期。 Azure 备份还会协调启用软删除，并在存储帐户中任何文件共享配置为用于备份时，立即对存储帐户添加删除锁定。 最后，Azure 备份提供某些关键的监视和警报功能，使客户能够获得其备份空间的合并视图。

可以使用 Azure 备份在 Azure 门户中执行项目级和共享级还原。 只需选择还原点（特定快照）、特定文件或目录（如相关），然后选择要还原到的位置（原始或备用）。 备份服务会处理复制快照数据，并在门户中显示还原进度。

使用 Microsoft Defender for Storage 保护 Azure 文件

Microsoft Defender for Storage 是一个 Azure 原生的安全智能层，用于检测对存储帐户的潜在威胁。 它通过分析 Azure 文件生成的数据平面和控制平面遥测来提供全面的安全性。 它使用由Microsoft威胁智能提供支持的高级威胁检测功能来提供上下文安全警报，包括缓解检测到的威胁并防止将来的攻击的步骤。

Defender for Storage 会持续分析由 Azure 文件存储生成的遥测数据流。 当检测到潜在的恶意活动时，将生成安全警报。 这些警报与可疑活动的详细信息、调查步骤、修补操作和安全建议一起显示在 Microsoft Defender for Cloud 中。

Defender for Storage 基于完整文件哈希（仅支持 REST API）来检测已知的恶意软件，例如勒索软件、病毒、间谍软件和其他上传到存储帐户的恶意软件。 这有助于防止恶意软件进入组织并传播给更多用户和资源。

Defender for Storage 不会访问存储帐户数据，也不会影响其性能。 可以在订阅级别（建议）或资源级别启用 Microsoft Defender for Storage。

存储分层

Azure 文件存储提供两个介质层存储：固态磁盘 (SSD) 和硬盘驱动器 (HDD)。 通过这些层，你可以根据方案的性能和价格要求定制共享：

• SSD（高级）：高级文件共享对 IO 密集型工作负载提供一致的高性能和低延迟，对于大多数 IO 操作，延迟不到 10 毫秒。 SSD 文件共享适合各种工作负载，例如数据库、网站托管和开发环境。

  可以将 SSD 文件共享与 SMB 和 NFS 协议一起使用。 SSD 文件共享在预配的 v2 和预配的 v1 计费模型中可用。 SSD 文件共享提供比 HDD 文件共享更高的可用性 SLA。

• HDD（标准）：HDD 文件共享为常规用途文件共享提供了经济高效的存储选项。 HDD 文件共享可用于预配的 v2 和即用即付计费模型，尽管我们建议对新的文件共享部署使用预配的 v2 模型。 有关 SLA 的信息，请参阅联机服务的 Azure SLA 页面。

为工作负载选择介质层时，请考虑性能和使用要求。 如果工作负荷需要一位数的延迟，或者在本地使用 SSD 存储介质，则 SSD 文件共享可能最合适。 如果低延迟并不算严重问题，则从成本的角度来看 HDD 文件共享可能更合适。 例如，对于从 Azure 装载在本地或通过 Azure 文件同步缓存的团队共享，低延迟可能不太算是个严重问题。

在存储帐户中创建文件共享后，无法直接将其移动到其他介质层。 例如，要将 HDD 文件共享移动到 SSD 介质层，必须创建新的 SSD 文件共享，并将原始共享中的数据复制到新的文件共享。

可以在了解 Azure 文件存储计费模型和了解和优化 Azure 文件共享性能中找到有关 SSD 和 HDD 介质层的详细信息。

Redundancy

为了帮助在 Azure 文件共享中保护数据以防数据丢失或损坏，Azure 文件存储会在写入每个文件时存储该文件的多个副本。 根据你的需求，可以选择不同程度的冗余。 Azure 文件存储目前支持以下数据冗余选项：

• 本地冗余存储 (LRS)：使用本地冗余时，每个文件在 Azure 存储群集中存储三次。 此方法有助于防止硬件故障（例如磁盘驱动器错误）导致的数据丢失。 但如果数据中心内发生火灾或洪水等灾难，则使用 LRS 的存储帐户的所有副本可能会丢失或无法恢复。

• 区域冗余存储（ZRS）：使用区域冗余，存储每个文件的三个副本。 但这些副本以物理方式隔离在不同 Azure 可用性区域的三个不同的存储群集中。 可用性区域是 Azure 区域中独特的物理位置。 每个区域由一个或多个数据中心组成，这些数据中心配置了独立电源以及散热和网络设备。 在将副本写入所有三个可用性区域的存储群集前，不允许将其写入存储。

• 异地冗余存储 (GRS)：使用异地冗余时，你会拥一个主要区域和一个次要区域。 文件在主要区域中的 Azure 存储群集中存储三次。 写入将异步复制到 Microsoft 定义的次要区域。

  异地冗余在两个 Azure 区域之间提供 6 个数据副本。 如果由于自然灾害或其他类似事件导致重大灾难（如某个 Azure 区域永久丢失），Microsoft 将会执行故障转移。 在这种情况下，次要区域将成为主要区域，以满足所有操作需求。

  由于主要区域和次要区域之间的复制是异步的，因此，在发生重大灾难时，尚未复制到次要区域的数据将会丢失。 还可以对异地冗余存储帐户执行手动故障转移。

• 异地区域冗余存储 (GZRS)：使用异地区域冗余时，文件在主要区域中的三个不同的存储群集中存储三次。 所有写入都将异步复制到 Microsoft 定义的次要区域。 异地区域冗余的故障转移过程与异地冗余的故障转移过程相同。

HDD 文件共享支持所有四种冗余类型。 SSD 文件共享仅支持 LRS 和 ZRS。

即用即付存储帐户提供了 Azure 文件存储不支持的另外两个冗余选项：读取访问异地冗余存储 (RA-GRS) 和读取访问异地区域冗余存储 (RA-GZRS)。 可以在存储帐户中使用这些选项集预配 Azure 文件共享，但 Azure 文件存储不支持从次要区域读取。 部署到 RA-GRS 或 RA-GZRS 存储帐户中的 Azure 文件共享分别作为异地冗余或异地区域冗余计费。

有关冗余的详细信息，请参阅 Azure 文件存储数据冗余。

区域冗余 SSD 文件共享的可用性

区域冗余 SSD 文件共享可用于 Azure 区域的子集。

灾难恢复和故障转移

在发生计划外的区域服务中断的情况下，应该为 Azure 文件共享制定灾难恢复 (DR) 计划。 要了解 DR 和存储帐户故障转移所涉及的概念和过程，请参阅 Azure 文件存储的灾难恢复和故障转移。

Migration

在很多情况下，你不想要为组织建立全新的文件共享，而是将现有文件共享从本地文件服务器或 NAS 设备迁移到 Azure 文件存储。 为你的场景选择正确的迁移策略和工具对于迁移的成功非常重要。

迁移概述文章简要介绍了基础知识，并包含一个表格，指引你查看适用于你的方案的迁移指南。

后续步骤

• 规划 Azure 文件同步部署
• 部署 Azure 文件
• 部署 Azure 文件同步
• 查看迁移概述文章，了解适用于你的方案的迁移指南