你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure Files 是 Microsoft 云文件存储解决方案。 Azure Files 提供服务器消息块 (SMB) 和网络文件系统 (NFS) 文件共享，你可以将其装载到云中、本地或两者中的客户端。 你还可以使用 Azure 文件同步在本地 Windows Server 上缓存 SMB 文件共享，并将不常用的文件分层到云中。
本文假设作为架构师，你已查看 了存储选项 ，并选择了 Azure 文件作为运行工作负荷的存储服务。 本文中的指南提供了与 Azure Well-Architected 框架支柱原则相对应的架构建议。
Reliability
可靠性支柱的目的是通过 建立足够的复原能力和从故障快速恢复来提供持续的功能。
可靠性设计原则提供了适用于各个组件、工作负荷、系统流和整个系统的高级设计策略。
工作负荷设计清单
根据可靠性设计评审核对清单开始实施您的设计策略。 确定其与业务需求的相关性，同时牢记应用程序的性质及其组件的关键性。 扩展策略以根据需要包含更多方法。
使用故障模式分析：通过考虑内部依赖关系（例如虚拟网络、Azure Key Vault、Azure 内容分发网络或 Azure Front Door 终结点的可用性）来最大限度地减少故障点。 如果你需要凭据来访问 Azure Files，而凭据在 Key Vault 中丢失，则可能会出现故障。 或者，如果你的工作负荷使用基于缺失的内容传送网络的终结点，则可能会出现故障。 在这些情况下，你可能需要将工作负荷配置为连接到备用终结点。 有关故障模式分析的一般信息，请参阅关于执行故障模式分析的建议。
定义可用性和恢复目标：查看 Azure 服务级别协议 (SLA)。 派生存储帐户的服务级别目标 (SLO)。 例如，你选择的冗余配置可能会影响 SLO。 考虑区域中断的影响、数据丢失的可能性以及中断后恢复访问所需的时间。 另外，请考虑你在故障模式分析中确定的内部依赖关系的可用性。
配置数据冗余：为了获得最大的持久性，请选择跨可用性区域或全球区域复制数据的配置。 为了实现最大可用性，请选择允许客户端在主要区域中断期间从次要区域读取数据的配置。
设计应用程序： 将应用程序设计 为无缝转移，以便在主要区域不可用时从次要区域读取数据。 此设计注意事项仅适用于异地冗余存储 (GRS) 和地理区域冗余存储 (GZRS) 配置。 设计你的应用程序以正确处理中断，从而减少客户的停机时间。
探索可帮助你实现恢复目标的功能：使文件可恢复，以便你可以恢复损坏、编辑或删除的文件。
创建恢复计划：考虑数据保护功能、备份和还原操作或故障转移程序。 为潜在的数据丢失和数据不一致以及故障转移的时间和成本做好准备。 有关详细信息，请参阅有关设计灾难恢复策略的建议。
监视潜在的可用性问题：订阅 Azure 服务运行状况仪表板以监视潜在的可用性问题。 使用 Azure Monitor 中的存储指标和诊断日志来调查警报。
配置建议
| Recommendation | Benefit |
|---|---|
| 配置存储帐户以实现冗余。 为了获得最大的可用性和持久性，请为你的帐户配置区域冗余存储 (ZRS)、GRS 或 GZRS。 有限数量的 Azure 区域支持 ZRS，用于 标准 和 SSD（高级） 文件共享。 只有标准 SMB 帐户才支持 GRS 和 GZRS。 高级 SMB 共享和 NFS 共享不支持 GRS 和 GZRS。 Azure 文件存储不支持读取访问异地冗余存储 (RA-GRS) 或读取访问异地区域冗余存储 (RA-GZRS)。 如果将存储帐户配置为使用 RA-GRS 或 RA-GZRS，文件共享会配置为 GRS 或 GZRS 并按这两项进行计费。 |
冗余可保护你的数据免受意外故障的影响。 ZRS 和 GZRS 配置选项可在各个可用性区域之间复制，并使应用程序能够在中断期间继续读取数据。 有关详细信息，请参阅持久性和可用性（按中断方案）和持久性和可用性参数。 |
| 在启动故障转移或故障回复之前，请检查上次同步时间属性的值以评估数据丢失的可能性。 此建议仅适用于 GRS 和 GZRS 配置。 | 此属性可帮助你估计在启动帐户故障转移的情况下可能会丢失多少数据。 上次同步时间之前写入的所有数据和元数据均可在次要区域上使用，但上次同步时间之后写入的数据和元数据可能会丢失，因为它们未写入次要区域。 |
| 作为备份和恢复策略的一部分，请启用软删除并使用快照进行时间点还原。 可以使用 Azure 备份 来备份 SMB 文件共享。 还可以使用 Azure 文件同步将本地 SMB 文件共享备份到 Azure 文件共享。 Azure 备份还允许对 Azure Files 进行保管备份，以保护数据免遭勒索软件攻击，或避免因恶意行为者或恶意管理员而导致源数据丢失。通过使用保管的备份，Azure 备份功能会复制数据并将其存储在恢复服务保管库中。 这会创建一个最多可保留 99 年的数据异地副本。 Azure 备份根据备份策略中定义的计划和保留时间创建和管理恢复点。 了解详细信息。 |
软删除适用于文件共享级别，可防止意外删除 Azure 文件共享。 时间点还原功能可以防止意外删除或损坏，因为你可以将文件共享还原到较早的状态。 有关详细信息，请参阅数据保护概述。 |
安全性
安全支柱的目的是为工作负荷提供 保密性、完整性和可用性 保证。
安全设计原则通过将方法应用于文件存储配置的技术设计，提供实现这些目标的高级设计策略。
安全要求和建议取决于工作负荷是使用 SMB 还是 NFS 协议来访问你的文件共享。 因此，以下部分针对 SMB 和 NFS 文件共享有单独的设计清单和建议。
作为最佳实践，你应该将 SMB 和 NFS 文件共享保存在单独的存储帐户中，因为它们具有不同的安全要求。 使用此方法可以为你的工作负荷提供强大的安全性和高度的灵活性。
SMB 文件共享的工作负荷设计清单
根据安全性性设计评审核对清单开始实施你的设计策略。 确定漏洞和控制以提高安全态势。 扩展策略以根据需要包含更多方法。
审查 Azure 存储的安全基线：首选，审查存储的安全基线。
考虑使用网络控制来限制入口流量和出口流量：在某些情况下，你可能愿意将你的存储帐户向公共 Internet 公开，例如，如果你使用基于身份的身份验证来授予对文件共享的访问权限。 但我们建议你使用网络控制来授予用户和应用程序所需的最低级别访问权限。 有关详细信息，请参阅如何实现存储帐户的网络安全性。
减小攻击面：在传输过程中使用加密并防止通过非安全 (HTTP) 连接进行访问以减小攻击面。 要求客户端使用最新版本的传输层安全性 (TLS) 协议发送和接收数据。
尽量少使用存储帐户密钥：与使用存储帐户密钥相比，基于标识的身份验证可提供更高的安全性。 可以使用 SMB 管理员的 Windows 权限模型 获取文件或目录的所有权，并在不使用存储帐户密钥的情况下配置 Windows ACL。 仅授予安全主体执行任务所需的必要权限。
保护敏感信息：保护敏感信息，例如存储帐户密钥和密码。 我们不建议你使用这些形式的授权，但如果你这样做，则应该确保轮换密码、使密码过期和安全存储密码。
检测威胁：启用 Microsoft Defender for Storage ，以检测通过 SMB 或 FileREST 协议访问或利用 Azure 文件共享的潜在有害尝试。 订阅管理员还获取电子邮件警报，其中详述了可疑活动以及有关如何调查和修正威胁的建议。 Defender for Storage 不支持 Azure 文件共享的防病毒功能。 如果你使用 Defender for Storage，则事务密集型文件共享会产生大量成本，因此，请考虑针对特定存储帐户选择退出 Defender for Storage。
SMB 文件共享的配置建议
| Recommendation | Benefit |
|---|---|
| 对存储帐户应用 Azure 资源管理器锁。 | 锁定帐户以防止因意外或恶意删除存储帐户而导致数据丢失。 |
| 打开出站 TCP 端口 445 或设置 VPN 网关或 Azure ExpressRoute 连接，以便 Azure 外部的客户端访问文件共享。 | SMB 3.x 是一种 Internet 安全协议，但你可能无法更改组织或 ISP 政策。 你可以使用 VPN 网关或 ExpressRoute 连接作为替代选项。 |
| 如果打开端口 445，请确保在 Windows 和 Linux 客户端上禁用 SMBv1。 Azure Files 不支持 SMB 1，但你仍应在客户端上禁用它。 | SMB 1 是一个已过时的低效且不安全的协议。 在客户端上禁用它可以改善你的安全态势。 |
| 考虑禁止通过公共网络访问你的存储帐户。 仅当 Azure 外部的 SMB 客户端和服务需要访问你的存储帐户时，才启用公共网络访问。 如果你禁用公用网络访问，请为你的存储帐户创建一个专用终结点。 专用终结点的标准数据处理速率适用。 专用终结点不会阻止连接到公共终结点。 你仍然应该按照前面所述禁用公共网络访问。 如果你不需要为文件共享使用静态 IP 地址，并且希望避免专用终结点的成本，则可以改为使用限制公共终结点访问，以便只能访问特定的虚拟网络和 IP 地址。 |
网络流量通过 Microsoft 主干网络而不是公共 Internet 传输，从而消除了来自公共 Internet 的风险暴露。 |
| 启用限制对特定虚拟网络的访问的防火墙规则。 从零访问开始，然后有条不紊地逐步提供客户端和服务所需的最少量访问权限。 | 最大限度地降低为攻击者创造机会的风险。 |
| 如果可能，请使用 基于标识的身份验证 和 AES-256 Kerberos 票证加密来授权访问 SMB Azure 文件共享。 | 使用基于标识的身份验证来降低攻击者使用存储帐户密钥访问文件共享的可能性。 |
| 如果你使用存储帐户密钥，请将其存储在密钥保管库中，并确保定期重新生成它们。 你可以通过从共享的 SMB 安全设置中删除 NTLMv2 来完全禁止使用存储帐户密钥访问文件共享。 但通常不应从共享的 SMB 安全设置中删除 NTLMv2，因为管理员仍可能需要将存储帐户密钥用于某些任务。 |
使用密钥保管库在运行时检索密钥，而不是将它们与应用程序一起保存。 密钥保管库可以轻松轮换密钥，而无需中断应用程序。 定期轮换帐户密钥以降低数据遭受恶意攻击的风险。 |
| 大多数情况下，你应该对所有存储帐户启用需要安全传输选项，以对 SMB 文件共享启用传输中加密。 如果你需要允许非常旧的客户端访问共享，请不要启用此选项。 如果你禁用安全传输，请务必使用网络控制来限制流量。 |
此设置可确保针对存储帐户发出的所有请求都通过安全连接 (HTTPS) 进行。 通过 HTTP 发出的任何请求都将失败。 |
| 配置你的存储帐户以使 TLS 1.2 成为客户端发送和接收数据的最低版本。 | TLS 1.2 比 TLS 1.0 和 1.1 更安全、更快速，后者不支持新式加密算法和密码套件。 |
| 仅使用最新支持的 SMB 协议版本（当前为 3.1.1.），并且仅使用 AES-256-GCM 进行 SMB 通道加密。 Azure 文件存储公开了一些设置，你可以使用这些设置根据组织要求切换 SMB 协议，使其更具兼容性或更安全。 默认情况下，允许使用所有 SMB 版本。 但是，如果你启用要求安全传输，则不允许使用 SMB 2.1，因为 SMB 2.1 不支持传输中数据的加密。 如果将这些设置限制为高安全级别，则某些客户端可能无法连接到文件共享。 |
随 Windows 10 一起发布的 SMB 3.1.1 包含重要的安全和性能更新。 AES-256-GCM 提供更安全的通道加密。 |
NFS 文件共享的工作负荷设计清单
审查存储的安全基线：首选，审查存储的安全基线。
了解组织的安全要求：NFS Azure 文件共享仅支持使用 NFSv4.1 协议的 Linux 客户端，并支持 4.1 协议规范中的大多数功能。 某些安全功能不受支持，如 Kerberos 身份验证和访问控制列表 (ACL)。
使用网络级安全和控制来限制入口流量和出口流量：基于标识的身份验证不适用于 NFS Azure 文件共享，因此你必须使用网络级安全和控制来授予用户和应用程序所需的最低级别访问权限。 有关详细信息，请参阅如何实现存储帐户的网络安全性。
NFS 文件共享的配置建议
| Recommendation | Benefit |
|---|---|
| 对存储帐户应用资源管理器锁。 | 锁定帐户以防止因意外或恶意删除存储帐户而导致数据丢失。 |
| 你必须在 NFS 共享要装载到的客户端上打开端口 2049。 | 打开端口 2049 以让客户端与 NFS Azure 文件共享进行通信。 |
| NFS Azure 文件共享只能通过受限网络访问。 因此，你必须为你的存储帐户创建专用终结点，或者限制公共终结点访问以便只允许访问选定的虚拟网络和 IP 地址。 建议创建专用终结点。 我们建议为 NFS 共享配置网络级安全性。 还可以 在传输中启用加密。 标准数据处理速率适用于专用终结点。 如果你不需要文件共享的静态 IP 地址，并且想要避免产生专用终结点成本，则可以限制公共终结点访问。 |
网络流量通过 Microsoft 主干网络而不是公共 Internet 传输，从而消除了来自公共 Internet 的风险暴露。 |
| 考虑禁止在存储帐户级别访问存储帐户密钥。 你不需要此访问权限即可装载 NFS 文件共享。 但请记住，对 NFS 文件共享的完全管理控制（包括拥有文件的能力）需要使用存储帐户密钥。 | 不允许使用存储帐户密钥，以使你的存储帐户更安全。 |
成本优化
成本优化侧重于 检测支出模式、优先考虑关键领域的投资，以及优化其他 以满足组织预算，同时满足业务需求。
成本优化设计原则提供了一种高级设计策略，此策略用于实现这些目标并在与文件存储及其环境相关的技术设计中根据需要进行权衡。
工作负荷设计清单
根据投资的成本优化设计评审核对清单开始实施您的设计策略。 微调设计，使工作负荷与为工作负荷分配的预算保持一致。 设计应使用正确的 Azure 功能，监视投资，并查找随时间推移进行优化的机会。
确定工作负荷是否需要 SSD（高级）文件共享的性能，或者标准 HDD 存储是否足够：根据所需的存储类型确定存储帐户类型和计费模型。 如果需要每秒大量的输入/输出作（IOPS）、极快的数据传输速度或非常低的延迟，则应选择 SSD Azure 文件共享。 NFS Azure 文件共享仅适用于 SSD 媒体层。 NFS 和 SMB 文件共享的价格与 SSD 的价格相同。
为文件共享创建存储帐户并选择冗余级别：选择标准 (GPv2) 或高级 (FileStorage) 帐户。 你选择的冗余级别会影响成本。 冗余度越高，成本越高。 本地冗余存储 (LRS) 最经济实惠。 GRS 仅适用于标准 SMB 文件共享。 标准文件共享仅显示存储帐户级别的交易信息，因此我们建议你在每个存储帐户中仅部署一个文件共享，以确保完整的计费可见性。
了解账单的计算方式：Azure 文件提供三种不同的计费模型：即 按需付费、预配 v2 和 预配 v1。 即用即付模型可以经济高效，因为只需为使用的内容付费;无需根据性能要求或需求波动过度预配或取消预配存储。 在即用即付模型中，计量器会跟踪帐户中存储的数据量或容量，以及基于你对这些数据的使用情况的交易数量和类型。 在预配的模型中，可以提前指定并支付一定数量的容量、IOPS 和吞吐量。
但你可能会发现将存储规划为预算过程的一部分很困难，因为最终用户的消耗决定了成本。 使用预配的模型时，事务不会影响计费，因此成本易于预测。 但无论你是否使用，都需要为所预配的存储容量付费。 有关如何计算成本的详细明细，请参阅了解 Azure 文件存储计费。
估算容量和运营成本：您可以使用 Azure 定价计算器来模拟与数据存储、流入量和流出量相关的成本。 比较与不同地区、帐户类型和冗余配置相关的成本。 有关详细信息，请参阅 Azure 文件定价。 还可以参考 文件共享总拥有成本清单。
选择最具成本效益的访问层：标准 SMB Azure 文件共享提供三个访问层：事务优化层、热层或冷层。 所有这三层都存储在相同的标准存储硬件上。 这三个层级的主要区别是静态数据存储价格（层级越冷，价格越低）和事务价格（层级越冷，价格越高）。 有关详细信息，请参阅标准层的区别。
确定您需要哪些增值服务：Azure Files 支持与备份、Azure 文件同步和 Defender for Storage 等增值服务集成。 这些解决方案有自己的许可和产品成本，但通常被视为文件存储总拥有成本的一部分。 如果你使用 Azure 文件同步，请考虑其他成本方面。
创建防护措施：基于订阅和资源组创建 预算 。 使用治理策略来限制资源类型、配置和位置。 此外，使用基于角色的访问控制 (RBAC) 来阻止可能导致超支的行为。
监视成本：确保成本保持在预算内，将成本与预测进行比较，并查看出现超支的情况。 可以使用 Azure 门户中 的成本分析 窗格来监视成本。 你还可以将成本数据导出到存储帐户，并使用 Excel 或 Power BI 分析该数据。
监视使用情况：持续监视使用模式，以检测未使用或未使用的存储帐户和文件共享。 检查容量是否有意外增加，这可能表明你正在收集大量日志文件或软删除的文件。 制定一种删除文件或将文件移到更具成本效益的访问层的策略。
配置建议
| Recommendation | Benefit |
|---|---|
| 迁移到标准 Azure 文件共享时，建议在初始迁移期间在 事务优化 层中启动。 迁移期间的事务使用情况通常并不表示正常的事务使用情况。 此注意事项不适用于 SSD 文件共享，因为预配的计费模型不收取事务费用。 | 迁移到 Azure Files 是一项临时的、事务密集型工作负荷。 优化高事务性工作负荷的价格，以帮助降低迁移成本。 |
| 迁移工作负荷后，如果使用标准文件共享，请仔细为文件共享选择最经济高效的访问层： 热、 冷或 事务优化。 在正常使用几天或几周后，可以将您的事务计数插入到定价计算器中，以确定哪一个套餐最适合您的工作负荷。 大多数客户应该选择 冷却 ，即使他们积极使用共享功能。 但是你应该检查每个共享并将存储容量余额与交易进行比较以确定你的层级。 如果交易成本占账单的很大百分比，那么使用 冷 访问层所节省的费用通常会抵消这些成本，并将总成本降到最低。 我们建议你仅在必要时在访问层之间移动标准文件共享，以优化工作负荷模式的变化。 每次移动都会发生交易。 有关详细信息，请参阅在标准层之间切换。 |
为标准文件共享选择适当的访问层，以大幅降低你的成本。 |
| 如果使用预配的计费模型，请确保为工作负荷预配足够的容量和性能，但不会产生不必要的成本。 我们建议超量预配两到三倍。 可以根据存储和输入/输出（IO）性能特征，动态增加或减少 SSD 文件共享的规模。 | 以合理的方式过度预配 SSD 文件共享，以帮助维护性能和考虑未来的增长和性能要求。 |
| 使用 Azure Files 预留（也称为预留实例）预先提交存储用量并获得折扣。 对具有一致占用空间的生产工作负荷或开发/测试工作负荷使用预留。 有关详细信息，请参阅通过存储预留来优化成本。 预留不包括交易、带宽、数据传输和元数据存储费用。 |
三年预留可为文件存储总成本提供高达 36% 的折扣。 预留不会影响性能。 |
| 监视快照使用情况。 快照会产生费用，但会根据每个快照的差异存储使用情况进行计费。 你只需支付每个快照的差额。 有关详细信息，请参阅 快照。 Azure 文件同步将共享级别和文件级别快照作为常规使用的一部分，这可能会增加你的 Azure 文件总费用。 |
差异快照可确保你不会因存储相同数据而被多次收费。 但是，你仍然应该监视快照使用情况，以帮助减少 Azure Files 计费。 |
| 设置软删除功能的保留期，尤其是在首次开始使用时。 考虑从较短的保留期开始，以便更好地了解该功能如何影响你的计费。 建议的最短保持期为七天。 软删除文件共享时，会将其计费为已用容量，而不是预配容量。 SSD 文件共享在软删除状态下按快照速率计费。 而处于软删除状态的标准文件共享按常规费率计费。 |
设置保留期，以便软删除的文件不会堆积并增加容量成本。 在配置的保留期之后，永久删除的数据不会产生费用。 |
卓越运营
卓越运营主要侧重于 开发实践、可观测性和发布管理的各个过程。
卓越运营设计原则 提供了一个高级设计策略，用于实现这些运营需求目标。
工作负荷设计清单
根据卓越运营设计评审清单来开始实施设计策略，以定义与文件存储配置相关的可观测性、测试和部署。
创建维护和紧急恢复计划：考虑数据保护功能、备份和还原操作以及故障转移程序。 为潜在的数据丢失和数据不一致以及故障转移的时间和成本做好准备。
监视存储帐户的运行状况：创建存储见解仪表板以监视可用性、性能和弹性指标。 设置警报以在客户注意到你的系统中的问题之前找出和解决问题。 使用诊断设置将资源日志路由到 Azure Monitor 日志工作区。 然后，你可以查询日志来更深入地调查警报。
定期检查文件共享活动：共享活动可能会随着时间而改变。 将标准文件共享移至较冷的访问层，或者你可以为高级共享预配或取消预配容量。 当你将标准文件共享移到其他访问层时，会产生交易费用。 仅在需要时再移动标准文件共享以减少每月帐单的费用。
配置建议
| Recommendation | Benefit |
|---|---|
| 使用基础结构即代码 (IaC) 在 Azure 资源管理器模板（ARM 模板）、Bicep 或 Terraform 中定义存储帐户的详细信息。 | 可以使用现有的 DevOps 进程来部署新的存储帐户，并使用 Azure Policy 强制实施其配置。 |
| 使用存储见解来跟踪存储帐户的运行状况和性能。 存储见解提供了所有存储帐户的故障、性能、可用性和容量的统一视图。 | 你可以跟踪每个帐户的运行状况和运行情况。 轻松创建仪表板和报表，利益相关者可以使用它们来跟踪存储帐户的运行状况。 |
| 使用 Monitor 分析指标，例如可用性、延迟和使用情况，以及 创建警报。 | 监视器提供文件共享的可用性、性能和弹性的视图。 |
| 请考虑将 Azure 文件同步 Arc 扩展 用于已启用 Arc 的 Windows Server 的混合环境。 | 启用跨多云和边缘环境的文件同步部署，同时通过 Azure 集中管理。 这简化了分布式制造、零售或远程办公室方案中的操作。这些方案需要在多个位置之间实现一致的文件访问，并且通过基于 Azure 的简化管理来实现。 |
性能效率
性能效率就是通过管理容量来保持用户体验，即使负载增加也不例外。 该策略包括缩放资源、识别和优化潜在瓶颈，以及优化峰值性能。
性能效率设计原则 提供了一个高级设计策略，用于根据预期使用量实现这些容量目标。
工作负荷设计清单
根据性能效率设计评审清单开始设计策略。 定义一个基于文件存储配置的关键绩效指标的基线。
规划缩放：了解存储帐户、Azure Files 和 Azure 文件同步的可伸缩性和性能目标。
了解你的应用程序和使用模式以实现可预测的性能：确定延迟敏感度、IOPS 和吞吐量要求、工作负荷持续时间和频率以及工作负荷并行化。 将 Azure Files 用于多线程应用程序以帮助你达到服务的性能上限。 如果你的大多数请求都以元数据为中心，例如 createfile、openfile、closefile、queryinfo 或 querydirectory，则这些请求会产生比读取和写入操作更高的延迟。 如果遇到此问题，并且使用的是 SSD SMB 文件共享，请启用 元数据缓存。 还可以尝试将文件共享拆分为同一存储帐户中的多个文件共享。
选择最佳存储帐户类型：如果你的工作负荷需要大量的 IOPS、极快的数据传输速度或非常低的延迟，那么你应该选择高级 (FileStorage) 存储帐户。 你可以将标准通用 v2 帐户用于大多数 SMB 文件共享工作负荷。 两种存储帐户类型之间的主要权衡是成本与性能。
预配的共享大小、IOPS、出口、入口和单文件限制决定了 SSD 文件共享性能。 如果需要暂时超过文件共享的基线 IOPS 限制，SSD 文件共享还提供 突发信用额度 作为保险单。
在与连接客户端相同的区域中创建存储帐户以减少延迟：距离 Azure Files 服务越远，延迟越长，并且越难达到性能缩放限制。 当你从本地环境访问 Azure Files 时，尤其需要注意这一点。 如果可能，请确保你的存储帐户和客户端共同位于同一个 Azure 区域中。 通过最大限度地减少网络延迟或使用 ExpressRoute 连接通过专用连接将本地网络扩展到 Microsoft 云来针对本地客户端进行优化。
收集性能数据：监视工作负载性能，包括延迟、可用性和使用情况指标。 分析日志 以诊断超时和限流等问题。 创建警报 ，以在文件共享受到限制、即将受到限制或遇到高延迟时通知你。
针对混合部署进行优化：如果你使用 Azure 文件同步，则同步性能取决于许多因素：Windows Server 和底层磁盘配置、服务器和 Azure 存储之间的网络带宽、文件大小、数据集总大小以及数据集上的活动。 要衡量基于 Azure 文件同步的解决方案的性能，请确定每秒处理的对象（例如文件和目录）的数量。
配置建议
| Recommendation | Benefit |
|---|---|
| 为 SSD SMB 文件共享启用 SMB 多通道 。 SMB 多通道允许 SMB 3.1.1 客户端与 SMB Azure 文件共享建立多个网络连接。 仅当在客户端（你的客户端）和服务端 (Azure) 中启用此功能时，SMB 多通道才可发挥作用。 在 Windows 客户端上，SMB 多通道默认已启用，但你需要在存储帐户上启用它。 |
提高吞吐量和 IOPS，同时降低总体拥有成本。 性能优势随着分摊负荷的文件数量的增加而增加。 |
| 为 SSD SMB 文件共享启用 元数据缓存 。 元数据缓存可降低元数据延迟并提高元数据缩放限制。 | 提高延迟一致性和可用的 IOPS，并提高网络吞吐量。 |
| 将 nconnect 客户端装载选项与 Linux 客户端上的 NFS Azure 文件共享配合使用。 Nconnect 使你能够在客户端和 NFSv4.1 的 Azure Files 高级服务之间使用更多 TCP 连接。 | 大规模提高性能并降低 NFS 文件共享的总体拥有成本。 |
| 确保文件共享或存储帐户不受 限制，这可能会导致高延迟、低吞吐量或低 IOPS。 当达到 IOPS、流入量或流出量限制时，请求会受到限制。 对于标准存储帐户，限制发生在帐户级别。 对于高级文件共享，限制通常发生在共享级别。 |
避免限制以提供可能最佳的客户体验。 |
Azure 策略
Azure 提供了一组与 Azure Files 相关的广泛内置策略。 可以通过 Azure 策略审核上述一些建议。 例如，可以检查以下情况：
- 仅接受来自安全连接（例如 HTTPS）的请求。
- 共享密钥授权已被禁用。
- 网络防火墙规则已应用于该帐户。
- Azure Files 的诊断设置被设置为将资源日志流式传输到 Azure Monitor 日志工作区。
- 已禁用公用网络访问。
- Azure 文件同步配置有专用终结点以使用专用 DNS 区域。
为了进行全面治理，请查看 Azure Policy 内置存储定义以及可能会影响计算层安全性的其他策略。
Azure 顾问建议
Azure 顾问是一名个性化的云顾问，可帮助你遵循最佳做法来优化 Azure 部署。
有关详细信息，请参阅 Azure 顾问。
后续步骤
有关详细信息，请参阅 Azure Files 文档。