Azure Files：世界最大文件服务器的架构、优化与应用

时间线

• 2015年：Azure Files上线。Azure Files正式GA，提供完全托管的文件共享服务，支持SMB 3.0协议（包括加密和持久句柄功能）。
• 2016年：Azure File Sync公测。支持本地Windows服务器缓存Azure文件共享，提高本地访问性能。
• 2017年：Azure File Sync正式GA，增强混合云能力，支持更高效的文件共享管理。
• 2018年：安全性增强。增加静态加密、传输加密，以及SMB共享的AD身份验证支持。
• 2019年：NFS协议支持公测，扩展对Linux用户的兼容性。
• 2020年：NFS协议支持正式GA，使Linux客户端能够直接挂载Azure文件共享。
• 2021年：功能增强。SMB Multichannel正式GA，实现高级文件共享的对称吞吐量；引入NFSv4.1协议支持；软删除功能推出，支持在指定保留期内恢复已删除的文件，增强数据保护。
• 2022年：重大安全更新。Azure AD Kerberos身份验证正式GA，支持混合身份；SUSE Linux支持用于SAP HANA系统复制引入；Azure文件管理通过控制平面可用，支持RBAC。
• 2023年：持续优化。NFS Azure文件共享的Nconnect正式GA；Azure文件REST API支持使用OAuth身份验证正式GA。

• 2024年：最新更新。Azure Files异地冗余正式发布，适用于标准大型文件共享；高级SMB文件共享的元数据缓存进入公开预览；NFS Azure文件共享的软删除功能正式发布；Azure File Sync v19增强了对Windows Server 2025的支持。

关键技术

1. 架构基础

Azure Files构建于Azure存储架构之上，利用了Azure存储的核心组件，如分区层和流层，以实现高可用性、数据一致性和持久性。

• 数据存储：Azure Files使用Azure表存储元数据，使用Azure页面Blob存储文件数据。

• 数据分层：Azure Files根据数据的持久性需求进行分层管理。持久状态（如文件句柄、会话ID）存储在后端，而临时状态（如TCP套接字信息）则无需持久化，以确保在不同的系统组件间维持数据一致性和高可用性。

2. 高可用性

• 持久句柄：Azure Files支持SMB 3.0及以上版本的持久句柄，客户端可以在前端节点重启或故障转移时透明地重新连接到文件共享，无需中断正在进行的操作。
• 数据分层：通过将数据按持久性需求进行分层，Azure Files确保即使在服务重启或节点故障的情况下，也能保持数据可用性和一致性。

• 实时迁移：Azure Files支持跨存储集群的实时迁移，以实现负载均衡或硬件淘汰。通过DNS映射更新和客户端重定向机制，迁移过程对用户透明，最大程度地减少了服务中断。

3. 性能优化

• 元数据缓存：为了减少元数据操作（如文件创建、打开、关闭）的延迟，Azure Files引入了L1内存缓存和L2持久缓存。
• SMB多通道和NFS NConnect：Azure Files支持SMB多通道和NFS NConnect，支持多个TCP连接用于单个文件共享会话，从而提高吞吐量、IOPS和网络容错能力。

• 租约中断优化：通过缓存文件租约状态并优化租约中断流程，Azure Files减少了不必要的租约中断请求，从而缩短了文件打开操作的延迟。

4. 安全机制

• 多层安全：Azure Files提供多层安全机制，包括网络安全、RBAC、静态和传输中加密以及文件和目录ACL。
• 混合身份验证：Azure Files支持使用本地AD或Azure AD进行Kerberos身份验证，方便用户在混合环境中使用现有身份系统。

• Entra Kerberos：Azure Files引入了Entra Kerberos，支持使用混合标识（在本地AD中创建并同步到Azure AD的用户身份）挂载和访问文件共享，无需与本地域控制器建立网络连接。

5. REST互操作性

• REST API：Azure Files提供REST API，支持使用REST协议访问和管理文件共享。这为备份、云分层和ISV集成等场景提供了灵活性。

• Azure File Sync：Azure File Sync使用REST协议将云端数据缓存到本地服务器，使用户能够在享受云端存储优势的同时获得本地文件服务器的性能和功能。

6. 未来发展方向

• 持续性能改进：继续优化性能和可用性，以提供更高效的文件存储服务。
• 扩展协议支持：扩展协议支持，例如SMB 3.1.1支持，进一步提升跨平台互操作性。
• 增强与其他Azure服务的集成：Azure Files将加强与Azure AD、Azure Kubernetes服务等其他Azure服务的集成，以实现更加紧密的云环境协同。

• 推出增值服务：更多增值服务，如数据分析、机器学习等，进一步丰富Azure Files的功能，为企业提供更全面的服务解决方案。

常见问题解答

1. 什么是Azure Files？

Azure Files是一项完全托管的云文件存储服务，支持SMB和NFS协议。用户可以通过这些协议访问文件共享。它是云原生的，提供高可扩展性和可靠性，适用于将传统应用程序迁移到云端。

2. Azure Files支持哪些工作负载？

• 传统应用程序：如部门共享、应用程序文件存储等。
• 混合工作负载：通过Azure File Sync实现本地与云之间的文件同步。
• 云原生工作负载：为容器化应用提供持久存储，如AI/ML、DevOps等。

• 增值服务：如备份、缓存和迁移等，基于REST API的服务。

3. Azure Files如何确保高可用性？

数据分层：根据数据的持久性需求分层，确保节点重启时数据仍然可用。

持久句柄：支持SMB 3.x的持久句柄，客户端在节点故障时可以无缝恢复连接。

实时迁移：支持跨存储集群迁移，确保客户端能够持续访问数据，不会中断。

4. Azure Files如何优化性能？

• 元数据缓存：通过L1内存缓存和L2持久缓存，加速文件操作，减少对后端存储的访问。
• 多通道与NConnect：通过多个连接提升吞吐量和IOPS，降低延迟。

• 租约中断优化：缓存租约状态，减少文件打开时的延迟。

5. Azure Files如何处理安全性？

• 网络安全：通过虚拟网络和专用链接控制文件共享的网络访问。
• RBAC：基于角色的访问控制，精细管理存储帐户和文件共享的权限。
• 加密：支持静态数据加密和传输加密，确保数据安全。
• ACL：支持文件和目录级别的访问控制，进行精确权限管理。
• 混合身份：通过Entra Kerberos支持使用本地AD凭据进行身份验证，简化混合环境中的身份管理。

6. Azure Files如何与REST API互操作？

Azure Files REST API提供无状态接口，方便开发增值服务，如Azure File Sync和Azure备份。与SMB和NFS相比，REST API配置更简单，支持OAuth认证，且通过端口443进行访问，便于在各种网络环境下使用。

7. 什么是Azure File Sync？

Azure File Sync是一种混合云存储解决方案，将Azure Files内容缓存到本地服务器。它提供以下功能：

• 云分层：将常用文件缓存在本地，较少访问的文件存储在云中，节省本地存储空间。
• 快速灾难恢复：本地服务器故障时，可通过Azure File Sync快速将文件恢复到其他服务器。因元数据存储在云端，文件可随时从云中恢复。

Azure File Sync通过REST API高效同步本地与云端数据，实现便捷的文件管理。

文件系统工作负载并非新鲜事物。文件系统（包括SMB和NFS）已存在数十年。在此期间，客户将其用于各种工作负载。有些工作负载需要终端用户访问，而有些则需要应用程序访问。此外，这些工作负载跨多个平台 有些运行在Windows上，有些在Linux上，还有一些在macOS上。

文件系统用于跨多个平台和工作负载的共享存储。大家能猜到哪些工作负载正在迁移到云端吗？

答案是：全部！没错，就是全部。

当工作负载迁移到云时，这是一次重大转变。客户对云服务有着多重期望。

首先，与本地系统不同，云服务消除了维护停机时间。无需应用补丁或重新上线文件服务器。所有服务都必须始终在线、始终可用，且服务级别协议（SLA）至少为99.99%。更有趣的是，即便如此，客户仍然要求更高的可用性。

其次，客户不会一蹴而就地将工作负载迁移到云中。迁移通常是分阶段进行的。在这个混合过渡阶段，工作负载需要同时获得本地和云端的支持。

这些通常是传统工作负载，最初是根据SMB和NFS文件系统设计的。然而，当它们迁移到云时，客户期望在云端获得与本地系统相同的工作负载功能，并且能够实现现代化增强。

第三，作为云文件服务商，Azure Files可以从规模经济中受益，在开发和硬件成本方面获得显著节约。这些成本节省最终会转嫁给客户，使成本效率成为云迁移的首要考虑因素。

我们是如何解决工作负载多样性并满足客户期望的？我们采取了多种解决方案：

1. 本地访问：对于常规部门共享或分支办公室协作，我们提供Azure File Sync，它充当云中数据的本地缓存。这使得Windows文件服务器可以作为缓存使用，而所有数据都存储在云中。当客户需要混合访问时，通常会选择这种解决方案。
2. 协议支持：对于行业特定应用和其他使用SMB和NFS协议的应用程序，我们在云中从底层原生实现了这些协议。
3. 云原生工作负载：对于AI/ML或云原生工作负载，客户通常希望将服务迁移到容器化解决方案。为此，我们在云中提供Kubernetes服务。为了将Azure Files连接到Kubernetes，我们使用CSI驱动程序，它定义了容器化应用访问文件系统的连接语义。Azure Files是最早根据该规范编写CSI驱动程序的服务之一。
4. 增值服务：除了核心产品外，我们还提供备份、缓存和迁移服务。对于这些服务，客户和合作伙伴通常使用REST API。

从整体发展过程来看，我们最初支持在硬盘上使用SMB协议。随着时间推移，我们将支持扩展到了高级存储。

该系统具有高可用性，因为它部署在分布式平台上。这使得客户能够将他们的传统工作负载迁移到云中。

对于混合工作负载，我们提供Azure File Sync，将文件系统管理迁移到云端。备份、复制和其他关键操作完全在云端处理。

对于云原生工作负载，我们为Azure Kubernetes Service（AKS）或其他基于Kubernetes的部署提供访问语义。此外，我们还支持用于增值服务（如备份和迁移）的REST API。

在深入探讨Azure Files之前，我想先澄清它并不是简单地将Windows或Linux文件服务器重新托管在云中。相反，它是一个云原生、可扩展的分布式文件存储实现，从基础设施到架构都是从零开始构建的。

Azure Files是一个完全托管的文件共享解决方案，允许客户无缝地将关键任务应用程序迁移到云端。作为全球最大的分布式文件系统，Azure Files支持SMB和NFS v4.1的有状态协议。然而，这种规模也带来了独特的挑战，需要进行性能优化和改进。

在详细讨论这些细节之前，我先简要概述一下Azure存储架构。为了实现高可用性、一致性和持久性，Azure Files对于SMB和NFS v4.1协议是建立在Azure存储之上的。

客户可以通过单一端点访问其数据，该端点本质上是一个存储帐户名称（例如，`file` 或 `blob.core.windows.net`）。该端点提供一个IP地址，通过负载均衡器将请求路由到我们的某个前端节点。

前端节点作为协议端点，负责处理身份验证、授权、指标（Metrics）和日志记录。这些指标和日志可以通过Azure门户查看。请求从前端传递到分区层。

分区层是一个大规模可扩展的键值存储（Key-Value Store），能够理解Blob和文件的结构，同时确保Azure存储的一致性。该层中的每个后端节点负责特定的键范围，并为该范围提供流量服务。

从分区层开始，请求继续传递到流层，流层处理数据的比特和字节。所有发送到流层的数据都进行三重复制，保持三份副本以确保数据持久性。流层是一个仅追加的分布式文件系统，作为Azure存储的后端存储。

Azure Files使用Azure Tables和Azure Blobs作为其后端存储：

• Azure Tables：用于存储元数据
• Azure Page Blobs：用于写入文件数据

此外，Azure Tables支持将相关的表（键范围）进行分组，以便跨它们执行ACID事务。

例如，如果一个文件存在于Azure文件共享中，并且你想要打开一个句柄：

• 实体表（Entity Table）会更新该文件的元数据
• 句柄表（Handle Table）会更新与句柄相关的具体信息
• 对于SMB，如果打开了独占租约，租约表（Lease Table）会更新，以保持租约状态

这些分组表确保了一致性，并允许在单个事务中执行多个更新。

Azure Files是一个分布式文件系统，托管在多个节点上，这些节点可能因升级或维护而出现停机。因此，必须保持状态，以便：

• 如果客户端连接的前端节点发生故障，可以无缝重新连接到另一个前端节点
• 系统可以持续提供服务且不中断

为实现这一目标，Azure Files根据持久性需求对数据进行分层，有助于重新连接和恢复状态。SMB和NFS v4.1都是有状态协议，Azure Files支持这些状态以确保高可用性。

关于Azure Files的架构，内部而言，SMB和NFS v4.1是不同的协议头，但它们共享通用的设计和实现。只有在协议特定需求要求时，才会进行分离。

请求处理过程如下：

• 解析帐户名称（例如，`<account>.file.core.windows.net`）

• 请求通过负载均衡器路由到前端节点之一

Azure Files通过两种前端提供数据访问：

• 有状态前端：处理持久化状态，如文件句柄和会话ID

• 无状态前端：处理不需要持久化状态的简单请求

对于持久化状态，后端（分区层和流层）存储持久标识符：

• 持久文件ID
• 会话ID
• 句柄ID

• 字节范围锁

对于不需要持久化的临时状态（如TCP套接字细节或文件信用），Azure Files确保数据在网络中断或重新连接场景中仍然可访问。

例如，如果客户端断开连接并通过另一个前端重新连接，持久状态允许客户端无缝重新连接，不丧失任何功能。

我想强调三个在优化和解决挑战方面取得重大进展的关键领域：

• 高可用性（High Availability）
• 性能（Performance）
• 安全性（Security）

高可用性。

Azure Files由数百个节点组成。这些节点可能因升级或部署而重新启动。为确保服务不中断：

• 数据分层以保证持久性
• SMB协议（3.0及以上版本）支持持久句柄（Persistent Handle），使后端能够维持持久状态

这使客户端能够在前端节点重启期间透明地进行故障转移，保持服务可用性，无需人工干预。

举例说明：

• 客户A和客户B通过负载均衡器连接到同一共享
• 可能被路由到不同的前端节点
• 发生网络中断或断开连接时，Azure Files会在Azure Tables和Blob Storage中保存会话状态

这确保客户端能够无缝重新连接，无需任何人工干预，因为状态信息已存储在我们这端。

通过利用这些机制，Azure Files提供了高可用、一致且可扩展的分布式文件存储解决方案，支持关键任务应用程序。

实时迁移（Live Migration）

实时迁移是一个非常有趣的话题。设想这样一个场景：客户账户托管在存储集群上，一个区域内可能有多个这样的集群。有时需要将存储账户从一个集群迁移到另一个集群，原因可能包括负载均衡或淘汰旧硬件。

将客户数据从旧集群迁移到新集群的过程称为账户迁移，涉及几个阶段，其中四个关键步骤如下：

1. 数据复制：将数据从源集群复制到目标集群
2. DNS映射更新：更新`<account>.file.core.windows.net`的DNS映射，指向目标集群
3. 连接断开：断开客户端与源集群的连接
4. 客户端重定向：客户端刷新DNS条目后，连接到目标集群并继续获得服务

虽然这个过程在设计上是透明的，但当客户端未刷新DNS条目时可能会遇到挑战。例如，较旧的Linux客户端在执行文件I/O操作时可能遇到"主机宕机"或"权限被拒绝"等错误。

账户迁移的顺利路径场景

场景1 – DNS刷新成功

• 客户端通过负载均衡器连接到端点，请求被路由到源集群的SMB前端
• 为负载均衡，数据从源集群移动到目标集群
• 分区层元数据更新，反映账户现由目标集群提供服务
• DNS映射更新，断开客户端与源集群的连接

• 客户端刷新DNS条目后，接收新IP地址（如`172.A.B.C`），连接到目标集群并无缝处理后续请求

场景2 – 重定向工作流

• 与场景1类似，数据从源集群移动到目标集群并更新元数据
• 如果客户端未刷新DNS条目，将尝试重新连接源集群
• 源集群SMB前端将请求重定向到目标集群
• 响应通过源集群返回客户端，确保无缝体验

为处理重定向，源集群分区层的元数据包含一个过期时间。只要重定向元数据有效，系统就可以通过重定向路径处理请求。

然而，如果连接丢失且客户端未刷新DNS条目，重定向元数据可能过期，导致"主机宕机"或"权限被拒绝"等错误。

迁移挑战的解决方案

为解决这些挑战，我们实施了以下方案：

• 内存缓存：扩展的内存缓存延长了保持重定向元数据的时间窗口

• Linux内核修复：与Linux社区合作，将修复提交到主线Linux内核，确保DNS条目定期更新，防止过期条目导致连接问题

给客户的建议：

• 升级客户端操作系统，包含最新修复

结果：

• 服务器端更改将关键问题减少99%
• 计划将类似改进贡献给NFS v4.1社区

性能增强

性能是另一个关键关注点。我们的优化工作主要集中在客户端和服务器端，重点包括：

• 减少元数据延迟：提高元数据操作性能
• 提高客户端吞吐量：为工作负载提供更高吞吐量

• 最小化往返次数：减少客户端与服务器之间的网络往返

改善元数据延迟

某些工作负载，如持续集成/持续部署（CI/CD）流水线和虚拟桌面基础设施（VDI），涉及大量元数据操作。这些工作负载，尤其是使用SMB高级文件共享时，从降低延迟中受益显著。

优化元数据操作架构

我们改善元数据操作的方法：

• 有状态协议处理
• SMB和NFS v4.1客户端的请求通过分区层处理
• 数据写入流层三次，确保持久性，但会增加延迟
• 缓存机制
• 引入L1内存缓存，由分区层中的L2持久缓存支持

• 元数据操作（如文件创建或打开）不再需要三次写入磁盘，显著减少延迟

益处：

• 元数据操作延迟降低
• 元数据密集型工作负载的客户端性能提升

性能提升

这些增强带来显著改进：

• P50元数据延迟减少55%
• 高查询需求（高Query Depth，QD）下，元数据操作数量最多提高3倍

详细技术文档提供了额外资源。

提高吞吐量

SMB和NFS协议都支持Multichannel和NConnect。这两个功能使客户端能够使用多个TCP连接，从而提高吞吐量和IOPS性能。

所有TCP连接属于同一会话。在之前的场景中，如果只有一个TCP连接断开，且客户端在该连接上打开了100个文件句柄，客户端需要对所有句柄执行文件重新打开等状态管理操作。如果是持久句柄，这将导致延迟。

通过使用多个TCP连接，即使一个连接发生网络故障，仍可通过其他连接继续流量，确保会话通信不中断。这减少了状态管理相关操作，使系统能将更多精力集中于读写等I/O任务。

允许多个TCP连接为客户端服务，可以更好地进行成本优化，因为客户端虚拟机可以充分利用其容量。SMB的Multichannel在吞吐量和IOPS方面的提升是一个关键改进。目前正在推出Multichannel，计划在所有高级文件账户上默认启用，因为它为客户提供显著好处。

性能数据

对于大文件（1 MB及以上）：

• SMB Multichannel显示读取吞吐量提高2倍以上
• 写入吞吐量提高4倍以上

NFS与NConnect

• 对于大文件（1 MB及以上），使用NFS和NConnect时：

• 读取和写入吞吐量提升可达3-4倍

租约（Lease）中断优化

假设多个虚拟机尝试连接或打开文件，并请求独占租约，它们可能在实现某种互斥机制。最终获得独占租约的虚拟机执行工作负载。

然而，较旧的Linux客户端会遇到一个问题。工作流程如下：

• 一个客户端请求独占租约并获得读写独占（RWH）租约
• 第二个客户端请求独占租约，服务器向第一个客户端发送租约中断请求

• 较旧的Linux客户端通常不响应租约中断确认，导致服务器必须等待超时周期才能为其他客户端提供文件打开请求

当多个客户端反复尝试打开句柄并请求独占租约，随即关闭该句柄时，问题更加复杂。在高峰期，这种重复循环会显著增加延迟。

为解决这个问题，我们构建了一个内存缓存来存储文件的最后租约状态。通过启发式判断，如果租约状态显示有待处理的中断请求，我们直接授予RWH租约，而非发送租约中断请求。

这种方法的优点是：减少从服务器发送到客户端的租约中断请求数量，消除等待较旧客户端确认的需要，显著提高文件打开的延迟。

安全性

在当今环境中，单一安全解决方案已不足。安全性需要多层实现，包括：

• 网络安全
• 基于角色的访问控制（RBAC）
• 静态和传输中加密

• 通过访问控制列表（ACL）保护文件和目录

我们从头开始构建这些安全层。在此想重点探讨身份验证。

在SMB和NFS中，Kerberos是关键身份验证协议之一。迁移到云时，默认身份验证协议通常是OAuth。然而，在云中提供Kerberos身份验证需要创新思维。

客户视角下的迁移

从客户角度看，云迁移并非一蹴而就。客户通常在本地数据中心运行文件服务器，这些数据中心的合同期一般为5到10年。合同接近尾声时，客户开始考虑将文件系统迁移到云中。

在过渡期，客户希望将文件系统置于云中，同时保留本地身份系统，因为其他工作负载仍在本地。在这种混合模式中：

• 本地身份：文件系统使用本地AD访问
• 混合身份：本地AD与云身份系统同步用户和组，通过云身份访问文件系统

• 云身份：客户完全将身份系统迁移到云中

尽管部分客户直接采用云身份，但大多数选择混合身份方式。支持这种混合模型需要创新，因为传统身份提供者通常仅支持完全本地或完全基于云的身份系统。

为解决这个问题，我们引入了Entra Kerberos，使混合身份场景成为可能，无需在本地和云环境间进行复杂网络配置。

Entra（原Azure AD）通过Entra Domain Services（Entra DS）提供域控制器服务，使云部署的客户端虚拟机能够使用Entra Kerberos访问文件系统。

总结：

• 本地AD：适用于仍高度依赖本地设置的客户
• 混合身份：适用于渐进式云迁移客户
• 云身份：适用于云原生工作负载，计划在近期支持完整基于云的身份

使用Entra Kerberos挂载文件共享的用户体验

接下来说明使用Entra Kerberos挂载文件共享的用户体验。

为使Entra在Kerberos密钥分发中心（KDC）中发挥作用，我们必须构建两个功能：

• 启用Entra作为KDC
• 使Windows客户端虚拟机能理解云身份和云安全

完成这两步后，典型客户设置如下：

客户拥有本地AD，通过Entra Sync与Entra同步。本地创建的所有身份都同步到云中。某个虚拟机（如管理虚拟机）加入本地AD域。

该管理虚拟机随后可在云中创建存储账户。创建时，会在Entra中自动为该存储账户创建对象。管理员可为系统中所有用户设置文件和目录级别的访问控制列表（ACL）。这是必要的，因为安全标识符（SID）到用户主体名称（UPN）的映射仅在本地AD中可用。

设置完成后，用户挂载文件共享时，完全加入Entra的客户端虚拟机已拥有票据授予票据（TGT）。使用TGT，客户端虚拟机向Entra Kerberos请求服务票据。Entra Kerberos使用存储账户创建时生成的存储账户令牌加密服务票据。

服务票据返回客户端。客户端使用该票据进行SMB会话设置。如果存储账户能解密服务票据，它将创建包含所有SID的访问令牌，并嵌入服务票据。在共享级别，权限完全基于基于角色的访问控制（RBAC），基于对象标识符（OID）。OID与SID间存在映射，此过程在后台进行。

角色确定基于用户是贡献者、提升的贡献者还是读取者等。基于角色授予访问权限。确定访问权限后，NTFS权限和ACL接管，文件系统访问由ACL管理。

这一流程适用于任何虚拟机，即使不在本地网络中。因此，即便用户虚拟机不在本地，他们仍可通过Entra Kerberos通过互联网访问云文件共享。

第三种协议

除了SMB和NFS之外，我们还提供了第三种协议：REST互操作协议。REST使得能够访问相同的数据，并可以在通过SMB和NFS访问的数据上进行数据平面操作。

选择REST的几个原因：

• 无状态性：REST是无状态协议，而SMB和NFS是有状态协议。有状态协议需要更多通信开销，可能在网络上传输更多额外数据。
• 网络配置：
• SMB使用端口445
• NFS使用端口2049
• 启用这些端口对最终用户并非总是可行
• REST通过端口443运行，更易访问，无需特殊端口配置
• 身份验证协议：
• REST使用OAuth，比Kerberos更易设置

• 处理第三方独立软件供应商（Independent Software Vendor，ISV）时尤其有利

对于接受无状态性的场景，如备份，REST是理想选择。备份通常从快照复制数据到持久位置，REST的无状态特性非常适合。许多ISV场景也非常适合使用REST协议。

REST的成功案例：Azure File Sync

Azure File Sync本质上是将云端数据缓存到本地的服务。假设您有一台本地Windows服务器作为文件服务器。如需更换或扩容，只需安装Azure File Sync代理，将其转换为本地缓存。

代理安装完成后：

• 本地服务器充当缓存，处理SMB和NFS流量
• 用户通过SMB和NFS访问文件
• 实际数据仍存储在云端
• 元数据被拉取到本地服务器
• 用户点击文件时从云端获取并通过本地缓存提供服务

• 随时间推移，缓存不断构建，冷数据重新迁移回云端

这种设置意味着客户无需维护本地备份或应用程序。发生灾难时，如Windows文件服务器丢失：

• 只需重新安装Azure File Sync代理
• 快速设置另一台服务器
• 代理将恢复元数据
• 缓存将重新填充

这一切得以实现，是因为Azure Files与本地服务器间的云分层通过REST协议进行。Azure Backup也使用REST协议。尽管客户可通过SMB从本地Windows桌面或云端访问SMB和NFS共享，但同步、云分层和备份操作都通过REST协议完成。

总结

Azure Files是一个分布式云文件系统，支持通过SMB和NFS协议从Windows、Linux和macOS访问文件。我们通过Azure File Sync提供本地缓存功能，允许客户端可以在云端或本地运行。客户端可以是虚拟机（VM）或容器。

----------

参考资料：Utsav Mohata, Rena Shah. "SNIA SDC 2024 - Azure Files." YouTube, 18 Sep. 2024, https://www.youtube.com/watch?v=VDhafnoH5bk.

---【本文完】---

近期受欢迎的文章：

1. Google Cloud：面向AI/ML工作负载的存储设计

更多交流，可加本人微信

（请附中文姓名/公司/关注领域）